JBossDeveloper

Sohil,
The reason I need to use my own security realm is because this realm is shared by more than one application and JBoss Portal is just one of the applications deployed in JBoss that uses this shared realm.

The way I've implemented this -
* There is a shared security realm (and possibly, more than 1 at some point) used by multiple applications.
* I also have a use case for bypassing security (trusted application scenario, etc.), so I can't rely on container managed security and j_security_check as it would ALWAYS challenge the user and I don't want that in certain cases.
* So, I moved to using my own Servlet and have that do something like this:

UsernamePasswordHandler handler = new UsernamePasswordHandler(username,
 password);
 LoginContext context = new LoginContext("SecurityRealmName", handler);
 context.login();

"I would recommend integrating with JBoss Portal's security realm with your custom LoginModules. "

What do you exactly mean by this? JBoss Portal uses a "portal" security realm that uses the JBoss OOTB login modules. I've used my own security realm and that works just fine if I use container managed security (a.k.a j_security_check). So, the issue is not with the use of a new,custom security realm but rather the lack of using container managed security and using my servlet.

So, if there is an issue, it is not with using a custom security realm but with using a Servlet and invoking the LoginModule explicitly? Correct? Want to ensure that both of us are on the same page.

"sohil.shah@jboss.com" wrote:
Yes you are correct. New security realm is not the issue. Its inability of the Servlet Environment to properly populate the security information needed by JBoss Portal.

In fact why dont you try swicthing the portal security realm to your custom/shared security realm and its LoginModules. You will still need to use the deep JAAS/container managed approach, but you will be using the security realm which is shared by all your applications.

You should be able to do this by:

1/ Modify <application-policy name="portal"> inside jboss-portal.sar/conf/login-config.xml to
<application-policy name="{your security realm here}">

2/ Inside jboss-portal.sar/portal-server.war/WEB-INF/jboss-web.xml make <security-domain>java:jaas/portal</security-domain> to <security-domain>java:jaas/{your security realm here}</security-domain>

Note: even with this approach you will still need to use the container based/j_security approach for Portal to be properly populated with the security information.

btw- I have never tried swapping the realm this way for Portal. This is in theory, so let us know if this actually works ;)

Thanks

Okay, one step further. This is what I need:

public boolean checkPermission(PortalPermission permission) throws IllegalArgumentException, PortalSecurityException
 {
 try
 {
 // Get the current authenticated subject through the JACC contract
 Subject subject = (Subject)PolicyContext.getContext("javax.security.auth.Subject.container");

 //
 return checkPermission(subject, permission);
 }
 catch (PolicyContextException e)
 {
 throw new PortalSecurityException(e);
 }
 }

..and my guess is that after the authentication happens, the PolicyContext is set for "javax.security.auth.Subject.container" but this happens in a different thread. Therefore, when I do a servlet forward, this subject is not found as this is a new/different thread..

"sohil.shah@jboss.com" wrote:
ah ok-

I understand your situation now.

Ok in this case you have no choice but to go the Tomcat Valve/Custom Authenticator route.

This is the only place you can actually grab hold of the Tomcat Session and populate it with the Subject/Principals that will be propagated through to Portal.

Basically you have to simulate what the container managed security is doing inside of your own code, and not use container managed security.

The sample interaction would be something like:

1/ You have a Tomcat Valve that post-processes the request on your Authentication Servlet

2/ In this Post Processing, it will grab information populated by the Servlet and populate the Principal/Subject just the way the container does for Portal when using standard JAAS mechanism

For a look at how this is done, look at the Authenticator source code of Tomcat and you will be very much enlightened ;)

Thanks

"Ok in this case you have no choice but to go the Tomcat Valve/Custom Authenticator route. "

Sohil - thanks very much for suggesting this! I've successfully implemented a custom Tomcat Authenticator/Value, and that solves the problem, and I've been able to achieve exactly what I wanted.

Needless to mention, some hacks were required but it ultimately works!!

Cool, thanks again!