JBoss 4.0.1 SP1 and JOSSO

[thenomad]

Hey all,

I'm trying desperately to get JOSSO to work with JBoss 4.0.1. In my travels (with a lot of tracing), I've come across what appears to be the big reason it's not working at this juncture. It boils down to a change in JaasSecurityManager between 3.x and 4.x of JBoss in the authenticate method.

You see, right now, when the JOSSO code is calling to get the activeSubject (with this call: Subject activeSubject = securityMgr.getActiveSubject();), the result is coming back null.

When I compare the authenticate methods between 3.x and 4.x in the JaasSecurityManager, 3.x used to make a call to setActivePrincipal that's no longer being called in 4.x.

Here's the 3.x version of the code (the // <===== are my comments):

 private boolean authenticate(Principal principal, Object credential,
 Subject theSubject)
 {
 Subject subject = null;
 boolean authenticated = false;
 LoginException authException = null;

 try
 {
 // Clear any current subject
 SubjectActions.setActiveSubject(null); // <=====



 // Validate the principal using the login configuration for this domain
 LoginContext lc = defaultLogin(principal, credential);
 subject = lc.getSubject();

 // Set the current subject if login was successful
 if( subject != null )
 {
 // Copy the current subject into theSubject
 if( theSubject != null )
 {
 SubjectActions.copySubject(subject, theSubject);
 }
 else
 {
 theSubject = subject;
 }

 authenticated = true;
 // Build the Subject based DomainInfo cache value
 Subject cacheSubject = updateCache(lc, subject, principal, credential);
 // Associate the subject with the thread
 SubjectActions.setActiveSubject(cacheSubject); // <=====

 }
 }

...catch code snipped...

Here's the 4.x version:

 private boolean authenticate(Principal principal, Object credential,
 Subject theSubject)
 {
 Subject subject = null;
 boolean authenticated = false;
 LoginException authException = null;

 try
 {
 // Validate the principal using the login configuration for this domain
 LoginContext lc = defaultLogin(principal, credential);
 subject = lc.getSubject();

 // Set the current subject if login was successful
 if( subject != null )
 {
 // Copy the current subject into theSubject
 if( theSubject != null )
 {
 SubjectActions.copySubject(subject, theSubject);
 }
 else
 {
 theSubject = subject;
 }

 authenticated = true;
 // Build the Subject based DomainInfo cache value
 updateCache(lc, subject, principal, credential);
 }
 }
...catch code snipped...

As near as I can tell in the code, the setActiveSubject stuff in SubjectActions has been replaced by push/pop actions: pushSubjectContext

But no matter what, shouldn't securityMgr.getActiveSubject() return the active subject - especially if it's just been authenticated?

Thanks for your help!

Marc

[starksm64]

No, the getActiveSubject is not a reliable call as evidenced by the change in behavior. 4.0.x no longer has a side effect of setting the thread subject on return from the authenticate method. Its the jobs of the caller of authenticate to establish whether or not there is a caller.

[thenomad]

No, the getActiveSubject is not a reliable call as evidenced by the change in behavior. 4.0.x no longer has a side effect of setting the thread subject on return from the authenticate method. Its the jobs of the caller of authenticate to establish whether or not there is a caller.

Thanks for your reply. However, if it's not reliable, then the JaasSecurityManager class has other problems.

The doesUserHaveRole methods (both), and the getUserRoles method expect this to be reliable. And, just grepping around the source, I find several classes that seem to rely on this being a reliable method:

JBossAuthenticationHandler.java
SubjectSecurityProxy.java (several places)
SecurityDomainContext.java
SecurityDomainEditor.java
...Several others...

[starksm64]

So the user of those methods has to ensure that the active subject has been set. This is now decoupled from the authenticate call.

[thenomad]

So the user of those methods has to ensure that the active subject has been set. This is now decoupled from the authenticate call.

That makes sense. The only thing I haven't seen is an exposed setActiveSubject method anywhere. What I ended up doing is creating a PrivilegedAction that calls the SecurityAssociation.setSubject method. Can I assume that this is the correct entry point to make sure that the activeSubject is set properly?

It seems to work, but I'd like to be sure that I'm setting the correct thing.

Also, is there some 4.x-specific Jaas documentation that covers this? Everything I've seen so far documentation-wise on this topic seems to be specific to the 3.x line. I hate to ask questions if it's properly documented and I haven't managed to find the correct document.

Thanks again for your time,

Marc

[starksm64]

From the ejb security interceptor:

 Subject subject = new Subject();
 if (securityManager.isValid(principal, credential, subject) == false)
 {
...
 }
 else
 {
 SecurityActions.pushSubjectContext(principal, credential, subject);
 }
...
 // Now actually check if the current caller has one of the required method roles
 if (realmMapping.doesUserHaveRole(principal, methodRoles) == false)
 {
...
 }
...
 SecurityActions.popSubjectContext();

where the SecurityActions.* methods are just priviledged action encapsulated SecurityAssociation.* calls.

[sgonzalez]

There is a patch already to support JBoss 4.0.1 sp1 in JOSSO 1.2.1, you can find int here :

JOSSO Patches