PicketLink STS EJB Example fails: Princial anonymous ?

[bkrisler]

Hi,

I am trying to get the example working from the SAML EJB Integration with PicketLink STS article. The article was very clear and informative,

however when using the attached components, I can not get a successful run.

Running the Test code from the example, I get the following output:

Invoking token service to get SAML assertion for UserA
SAML assertion for UserA successfully obtained!
Invoking secure EJB3 session bean with UserA SAML assertion
User UserA is not authorized to call administrative method!
User UserA is not authorized to call regular method!
User anonymous successfully called unprotected method!
User UserA is not authorized to call unavailable method!

Invoking token service to get SAML assertion for UserB
SAML assertion for UserB successfully obtained!
Invoking secure EJB3 session bean with UserB SAML assertion
User UserB is not authorized to call administrative method!
User UserB is not authorized to call regular method!
User anonymous successfully called unprotected method!
User UserB is not authorized to call unavailable method!

Invoking token service to get SAML assertion for UserC
SAML assertion for UserC successfully obtained!
Invoking secure EJB3 session bean with UserC SAML assertion
User UserC is not authorized to call administrative method!
User UserC is not authorized to call regular method!
User anonymous successfully called unprotected method!
User UserC is not authorized to call unavailable method!

It is clear that I am obtaining SAML from STS, however the second validation fails because all users are seen as Anonymous.

Log excerpt:

2010-07-29 17:11:17,648 TRACE [org.jboss.security.SecurityRolesAssociation] (http-127.0.0.1-8080-1) Setting threadlocal:null
2010-07-29 17:11:17,648 TRACE [org.jboss.security.SecurityRolesAssociation] (http-127.0.0.1-8080-1) Setting threadlocal:null
2010-07-29 17:11:17,923 TRACE [org.jboss.security.SecurityRolesAssociation] (WorkerThread#1[127.0.0.1:37241]) Setting threadlocal:{}
2010-07-29 17:11:17,924 TRACE [org.jboss.security.plugins.authorization.JBossAuthorizationContext] (WorkerThread#1[127.0.0.1:37241]) Control flag for entry:org.jboss.security.authorization.config.AuthorizationModuleEntry{org.jboss.security.authorization.modules.DelegatingAuthorizationModule:{}REQUIRED}is:[REQUIRED]
2010-07-29 17:11:17,924 TRACE [org.jboss.security.authorization.modules.ejb.EJBPolicyModuleDelegate] (WorkerThread#1[127.0.0.1:37241]) method=public java.security.Principal org.jboss.test.security.ejb3.SimpleStatelessSessionBean.invokeAdministrativeMethod(), interface=Remote, requiredRoles=Roles(Administrator,)
2010-07-29 17:11:17,924 TRACE [org.jboss.security.authorization.modules.ejb.EJBPolicyModuleDelegate] (WorkerThread#1[127.0.0.1:37241]) Exception:Insufficient method permissions, principal=null, ejbName=SimpleStatelessSessionBean, method=invokeAdministrativeMethod, interface=Remote, requiredRoles=Roles(Administrator,), principalRoles=Roles()
2010-07-29 17:11:17,924 TRACE [org.jboss.security.plugins.authorization.JBossAuthorizationContext] (WorkerThread#1[127.0.0.1:37241]) REQUIRED failed for Name=org.jboss.security.authorization.modules.DelegatingAuthorizationModule:subject=Subject:
        Principal: anonymous
:role=Roles()

The incoming SOAP message has the correct user:

...
<Subject>
       <NameID NameQualifier='urn:picketlink:identity-federation'>UserA</NameID>
       <SubjectConfirmation Method='urn:oasis:names:tc:SAML:2.0:cm:bearer'/>
</Subject>
....

Is there something that I am missing?

Thanks for any help

Brian

[sguilhen]

Hi Brian,

What version of JBoss AS are you using? I'll try to run the example here to check if the doc contains all the information that is needed.

[bkrisler]

Hi,

I am running  5.1.0.GA.

Brian

[sguilhen]

Hi Brian,

can you confirm that the ejb3-sampleapp application policy has been installed? After deploying the sample app, go to the jmx console (http://localhost:8080/jmx-console), then select the XMLLoginConfig service, then go to the displayAppConfig operation, insert the ejb3-sampleapp domain in the text box and hit invoke. It should display the application policy config. Can you tell me if you're seeing the policy?

[bkrisler]

It looks like the policy exists:

ejb3-sampleapp LoginConfiguration
LoginModule Class: org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule

ControlFlag: LoginModuleControlFlag: required

Options:name=jboss.security.security_domain, value=ejb3-sampleapp
name=configFile, value=sts-config.properties
name=password-stacking, value=useFirstPass

LoginModule Class: org.jboss.security.auth.spi.UsersRolesLoginModule

ControlFlag: LoginModuleControlFlag: required

Options:name=usersProperties, value=ejb3-sampleapp-users.properties
name=jboss.security.security_domain, value=ejb3-sampleapp
name=rolesProperties, value=ejb3-sampleapp-roles.properties
name=password-stacking, value=useFirstPass

[sguilhen]

Hi Brian,

it looks like you're right. The EJB3 sample is not working on JBoss 5.1 because the propagated security context is null and this causes the container to use the anonymous identity for the calls. I'll investigate this a bit further and post here when I find the culprit.

Note: I've run the samples on JBoss AS 6 M3 and it worked fine. The EJB2 sample also works on both containers.

[anil.saldhana]

Stefan, there must have been a bug fix between AS51 and AS6 in ejb3.   I think it makes sense for Brian to just use AS6M3.

[bkrisler]

It shouldn't be a problem for me to switch version, but the documentation should get augmented to indicate the issue with running the example on 5.1.

Thanks!

Brian

[sguilhen]

The problem has been recorded by Scott in the following Jira: https://jira.jboss.org/browse/JBAS-7010. It has been fixed on EAP 5.0 and JBoss AS 6 M1 but it still affects JBoss 5.1.0.GA.

When I wrote the document I was using EAP 5.0, so I didn't get to see the error. A workaround would be to use JAAS on the client side to create the security context as opposed to using the JndiLoginInitialContextFactory. For this to work, an extra login module is needed on the client side to associate the SAML assertion with the security context as the standard ClientLoginModule only has callbacks for String passwords.

I'll open a Jira to create a STSClientLoginModule that retrieves the token from the STS and associates it with the client-side security context.

[sguilhen]

Brian,

I've created another EJB3 client app that uses the SecurityClient API as an alternative to JndiLoginInitialContextFactory and updated the document accordingly. The effect is just the same, both approaches insert the principal/assertion in the client-side security context. The only difference is that SecurityClient will work on JBoss AS 5.1.0.GA, unlike the JNDI approach that has an issue that prevents it from workin in this JBoss AS version.

Cheers and thanks for bringing this up.

Stefan