A question regarding the SAML and EJB integration

[sergeyb]

Hi

I've read the documentation describing the way PicketLink SAML can be used to protect EJBs (http://community.jboss.org/wiki/SAMLEJBIntegrationwithPicketLinkSTS), really well documented, thanks.

The question :

why does a username is propagated, along side with the SAML assertion containing the username ?

// invoke the remote EJB using the assertion as the credential.
this.env.put("java.naming.security.principal", username);
this.env.put("java.naming.security.credentials", new SamlCredential(assertion));

In the case I'm thinking about a username will not be available on the server side.
Is it possible not to specify the username once the assertion has been received, may be the SAML login module can
extract it from the (saml)credentials ?

thanks, Sergey

[anil.saldhana]

I think Stefan wanted to reuse the current EJB interceptors in JBoss rather than write a fresh one.  All the work then happens in the pluggable login modules.  Any change in the pattern of (Username,Cred) with ejb infra in JBoss will involve a new EJB server side security interceptor.

So you can write a server side interceptor to have your proposed pattern of the assertion providing the username.  But then you may have to write new login modules also.

[sguilhen]

From the SAML2STSLoginModule point of view, the principal is really not needed as the module is able to extract it from the SAML assertion. However, the  principal that is supplied by the client app is used to build the security context once the invocation reaches the EJB interceptors. If we pass a null principal, the module will succeed, but other opearations that may rely on the security context may fail. For instance, calling getCallerPrincipal might result in null, but this needs to be tested.

[sguilhen]

I've just tested calling the EJB without a principal and JNDILoginInitialContextFactory fails with a NPE, so the principal must not be null. If I supply an empty string, the call succeeds but getCallerPrincipal returns the very same empty string.

Anil, what do you think? The login module can create a group called CallerPrincipal and insert the assertion principal in there so that getCallerPrincipal returns this principal instead of the one that was set in the security context. But even if we do this we may come across a NPE if one of the interceptors doesn't like null principals.

[anil.saldhana]

In the absence of a principal, the EE container can adopt the unauthenticated identity.  So it basically means a bug if the interceptor throws an NPE at the first experience of a null principal.

Anyday I prefer an exception over an NPE.  Just create a JIRA issue for the NPE.