I'm so close but can't put the last nail in this coffin.
I have an .ear file. It houses a single EJB jar with a
@RolesAllowed({"admin"})-protected, @Remote EJB in it. The ear is valid and
deploys fine.
I have a unit test that looks this bean up.
In my pom I use the maven-embedded-glassfish-plugin to set up an embedded
instance of Glassfish. Before it comes up I add a file user
("scott"/"tiger"--hello,
Oracle fans) with "--groups admin" and set the default
principal-to-role-mapping to true (so that the group "admin" will get
silently bound to the role "admin").
I have a ProgrammaticLogin call that attempts to log in as "scott"/"tiger".
Then I look up the bean. I get a CORBA permission error.
Here is the (relevant) pom configuration (apologies to those of you
unfortunate enough to read this on the miserable Java.net "forum software"
(which is neither)):
<execution>
<id>Set up users</id>
<phase>pre-integration-test</phase>
<goals>
<goal>admin</goal>
</goals>
<configuration>
<commands>
<command>set
configs.config.server-config.security-service.activate-default-principal-to-role-mapping=true</command>
<command>create-file-user
--passwordfile=${project.build.testOutputDirectory}/passwordfile.txt
--groups admin scott</command>
</commands>
</configuration>
</execution>
The "set configs..." command is a cut-and-paste job from looking at the
output of asadmin list, so I know I have this syntax right. Additionally,
the log reports that this command has succeeded. So I have to assume that I
have turned on default Principal to role mapping, yes? Is there some other
way to check if indeed this is true?
The "create-file-user" command also succeeds. Here is a cut-and-paste of
the passwordfile.txt contents, taken straight from the target file:
AS_ADMIN_USERPASSWORD=tiger
I got the name of the property from the main asadmin help page.
The net effect, I would hope, is that (should he ever log in) good ol' "
scott" will have a password of "tiger" and a group of "admin". And, since
the default principal to role binding is on, he should also drop into the
role of "admin". That means he should be able to look up the bean protected
with that role.
Next up, my programmatic login is accomplished by first placing a
loginconfiguration.conf file in my Maven project's
src/test/resourcesdirectory (which means it will get copied into
target/test-classes, i.e. the ${project.build.testOutputDirectory}).
It looks like this:
default {
com.sun.enterprise.security.auth.login.ClientPasswordLoginModule required
debug=true;
};
Then in my pom I make sure that my maven-failsafe-plugin sets this as a
system property when it forks the VM, since otherwise I get an (actually
helpful) error message saying something about a missing login configuration:
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<executions>
<execution>
<id>Run integration tests</id>
<configuration>
<systemPropertyVariables>
<java.security.auth.login.config>${project.build.testOutputDirectory}/loginconfiguration.conf</java.security.auth.login.config>
</systemPropertyVariables>
<useFile>false</useFile>
</configuration>
<goals>
<goal>integration-test</goal>
</goals>
</execution>
<!-- etc. -->
</executions>
</plugin>
Then, finally, in my unit test, I do:
new ProgrammaticLogin().login("scott", "tiger");
...which completes normally, as you'd expect.
Then I do the bean lookup (which works fine when I remove the
@RolesAllowedannotation, so the lookup string is correct):
final Object bean = new
InitialContext().lookup("java:global/myapp/myejb-1.19-SNAPSHOT/HelloBean");
That fails with the NO_PERMISSION error.
I'm sure I'm overlooking something really obvious. What is it?
Thanks,
Laird