Hi,
When authenticating a Remote EJB the Client has to use a specific LoginModule configuration java.security.auth.login.config should be set to /glassfish/lib/appclient/appclientlogin.conf
It has definitions of special login modules which on the Client Side would collect the credentials and store it in a place such that when the IIOP remote request is sent these credentials are encoded into the CSIv2 header.
The server would then receive those creds and do the actual authentication on the server side. There is no real authentication happening on the client side as you might be aware.
regards,
kumar
On 05-Aug-2011, at 12:24 AM, Laird Nelson wrote:
> 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/resources directory (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 @RolesAllowed annotation, 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