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.
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.
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.
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.