New features for STS Login Modules

[bmozaffa]

STSIssuingLoginModule and STSValidatingLoginModule respectively issue and validate tokens being returned from STS. The concept of user roles is not an inherent features of this mechanism but various principals and roles can nonetheless be returned by STS in the form of Attributes of Claims. I suggest the following enhancement to these two login modules:

* Create a pluggable PrincipalProvider model where implementations of the PrincipalProvider interface can be configured on the login module and will be called upon to provide one or more Principal objects given a SAML token. These Principals would be inserted into the Subject by the LoginModule.

The interface could look like this:

public interface SAMLPrincipalProvider
{
      java.security.Principal[] getPrincipals(org.w3c.dom.Element samlToken );
}

[anil.saldhana]

The foundation "PicketBox" has the concept of MappingManagers where you can map "principal".  This can be used in the login modules such that the configuration of the mapping managers can come from the common security domain configuration.

[bmozaffa]

Hi Anil,

Based on what I could understood from the code, the mapping managers today help map principals, roles or the like. With our login modules, the resulting Subject contains neither principals nor roles, but rather an Assertion element in the Public Credentials. I don't believe the entire Subject is made available to the mapping provider for it to be able to create the principal / roles from there either.

Am I missing something? Are you suggesting that we can achieve this by configuration only and providing a new MappingProvider or by extending the framework?

Thanks, Babak

[anil.saldhana]

Since you are talking about returning Principals, the principal mapping framework should work.  You just need a principal provider that takes in the assertion and converts into a principal of your choice.

[bmozaffa]

I was under the impression that the mapping providers were being called automatically by the framework, given how they are configured in the application policy. It seems like they need to be called manually, in which case we can of course supply the SAML token and have them figure out the principal / group from it.

I gave this a try and implemented it but hit a dead-end on a dependency issue. Where would you call the mapping provider from? My assumption was the LoginModule but the Mapping Provider framework is part of the JBoss Security SPI and federation-core does not depend on that. Am I missing something here? We could of course do it in the JBoss bindings component but my impression was that we were trying to create a pluggable and portable solution that wouldn't tie into JBoss.

[anil.saldhana]

If everything happened magically, we dont need developers.

The idea of the mapping framework is that we have an API and a pluggable set of mapping providers which can be added to the same configuration in security domain as in authentication, authorization and audit.

The mapping API needs to be called at integration points across the server. Whether it be in a tomcat valve or a servlet filter or a EJB3 interceptor etc.   Anything we deal with principals, attributes, roles etc and we need to map,  this framework is just uniform and awesome.

Picketbox is a security framework for Java applications.  It is not specific to JBoss. We should be able to use the security-spi and jbosssx jars there.

[anil.saldhana]

Babak, do we have a JIRA issue for this?

https://jira.jboss.org/jira/browse/PLFED

[bmozaffa]

No, but we'll have one soon! :-)

[anil.saldhana]

The extra features that the login modules will get should not be enabled by default but triggered by the presence of module options.

[bmozaffa]

Yes, that's how I've implemented it. It will look for mapping providers and use them if they're configured in the security domain.