Help me understand how to configure existing SP for a single SP authenticating to two IdPs

[Cantor, Scott]

> The reply to my previous request directed me to some impressive
> documentation, which I have read and re-read to the point of information
> overload, but it was fun and easy creating, joining, configuring, and testing an
> SP on TestShib!  I'm happy to continue reading, but the deadline is near and I
> need help understanding how to configure Shibboleth2.xml for a single SP
> authenticating to two IdPs.

The general answer to that is that it just works when you add metadata and address discovery instead of assuming the IdP by statically configuring it.

My guess is you don't want that, but rather you want to create silos of resources tied to specific IdPs (this is known as "the way to prevent federation from ever working because resources are tied to specific IdPs, making resources sharing impractical for users"). That may in fact be ok for your use case, but I have no way to know that, and in general it's a really bad model that causes all of us pain, so my general response is that it sucks when vendors do that. But that's a generalized statement.

> My goal is to add another company, i.e. new.CompanyB.com, that has its
> own IdP, IdP.CompanyB.com, to my existing SP's SSO process.

There are a whole host of other considerations to this, like the issue above, whether resources are supposed to jointly be accessible to both IdPs, and whether you have the pieces in place application-wise to do authorization based on attributes so that you can load all the metadata in one spot. Within a single Application boundary in the SP, any of the IdPs for which metadata is loaded can in general deliver assertions to login to any resource. After that it's up to the authorization layer to enforce access.

If the app is unable to do that, then things get much more complex and you probably have no choice but to implement ApplicationOverride(s) so that you can load separate metadata for different resource sets preventing access by one IdP or the other.

In that situation, the best choice is to have separate vhosts for the different resources. What you do not want, unless you want imperfect security and more pain, is to segregate the resources by path. The wiki explains that in the NativeSPApplicationModel topic.

> NOTE: new.CompanyB.com wants to use userId instead of email.

That's fine, but don't use REMOTE_USER anyway, just use the attribute headers/variables desired, directly. If you insist on making REMOTE_USER different, it gets more complex, Peter covered various options, and there are others.

> 			<SSO 	entityId="http://IdP.CompanyA.com"
> discoveryProtocol="SAMLDS"
> 
> 	discoveryURL="https://www2.CompanyA.com/somepath/saml?targ
> et=mycompany"

Discovery settings are irrelevant if you set the IdP name. So that's meaningless. It's also not a discovery service URL, most likely, but it isn't affecting anything.

When you have multiple IdPs in the mix, then you can map resources or vhosts to the IdP to use by setting the entityID in the RequestMap or Apache content setting. That's how you skip discovery when there are > 1 IdP. That does *not* perform authorization based on IdP. IdPs are not meant to be an authorization criteria, attributes are.

But your example has the entityID setting inside the root RequestMap element, and it's doing you no good there, that's equivalent to putting it in the SSO element down below. If you want to control it based on content, it goes into Host or Path elements.
 
> 	target="https://test.mycompany.com/Path1/Path2/">

I doubt you have any need to hardwire the target value here.

> QUESTION: Can this file referenced in MetadataProvider hold metadata for
> more than one IdP? If so, wrapped in  an <EntitiesDescriptor> element?

Yes. Understanding all of the previous points: any IdPs trusted can be used to login to the resources. The rest is authorization. If that's not acceptable, then you cannot use a single Application definition in the SP config.

The model the SP is geared toward is to use one application, load metadata for any IdPs desired, and perform authorization based on the attriubutes you get from them, and never solely based on which IdP somebody came from. If you need something else, it gets more complex.

None of this conflicts with Peter's response, I'm just giving some additional conceptual points and noting the authorization aspects that I think most vendors don't seem to get.

-- Scott