Multi-tenant SP configuration

[mwp]

First up, Great Product. You have done such an awesome job with all this.

I have our application acting as a SP and successfully working with both CloudSeal and SSO Circle. One of my requirements is to support any number of IDPs. The way i have things configured at the moment is to have a single SP metadata, and multiple IDP meta data for each of the IDPs we are partnering with.

This would be my ideal way of configuring things, but I get the feeling that may not be flexible enough.

Some questions:

1) Am I right in thinking that with a single SP metadata as described above, we will not be able to get the fine grained control we want? ... So, when interacting with CloudSeal use HTTP-POST binding, but when interacting with SSO Circle, use HTTP-ARTIFACT binding ... As an example.

Reading the manual, it says:

The same instance of your application can include multiple statically declared local service providers each
differentiated with it's own unique alias and entity ID. Each service provider can e.g. process a different
domain or have different security key settings. This feature makes it possible to create multi-tenant applications
with individual SAML settings for each of the tenants. In case multiple local SPs are declared, property
hostedSPName of the metadata bean should be set to the entity ID of the default one.

... This sounds a lot like what i am thinking about trying to get working

2) Our SAML interaction is SP Initiated. We have a SAML secured endpoint that is posted into with a slab of xml and the idp set which causes the correct IDP to be selected. What I am not so clear on is how we would go about forcing a particular SP configuration to be used depending on the IDP if that makes sense? The hostedSPName property of the metadata bean doesn't look like it will help if this situation.

Let me know if the path I am going down is crazy ... I am very new to SAML so I dont know what I dont know

Thanks Again.

[vsch]

Hi,

It all depends on how fine-grained control you want to have. In case settings such as binding, nameID, passive, allowCreate, authncontext is all you need, the WebSSOProfileOptions is your friend. Just override method getProfileOptions in the SAMLEntryPoint and create an implementation which sets parameters the way you wish for each SSO request.

The context passed to the getProfileOptions method contains both local SP metadata (property localEntityMetadata) and metadata of the IDP selected with the IDP discovery (which you can also customize). So you should have all the data you need to make a decision on what settings to use.

If that's not enough and you'd like to e.g. use differente keys for each federation you can generate multiple SP metadata (just use the sample app UI) with different alias names. System then automatically selects the correct local SP based on URL (e.g. http://local/app/saml/SSO/alias/myAlias will tell system to create the request using SP metadata with alias 'myAlias'). You can also change the local SP selection logic by customizing the SAMLContextProviderImpl.

Thank you for the "awesome job with all this"

Vladi