+xI'm not sure how an identity provider could send SAML assertions to authenticate users from a different identity provider. You could require that identity providers include a SAML attribute in the SAML assertion that somehow delineates its users from any other users. The only unique name is the SAML metadata entityID which we call the <PartnerIdentityProvider> Name in the SAML configuration. If you wanted to check this name, I think the best solution would be for your application to maintain a mapping of these partner names to something more descriptive. Thank you for the quick response. Sorry if I wasn't clear -- this isn't a concern with the ComponentSpace product specifically, but SSO more generally I guess. As a SP, let's say I'm connected with two IdPs, "A" and "B". With IdP-initiated signon, I get a SAML token essentially asserting that "This user is [email protected], he's signed in over here and has claims for x, y, and z. Signed, IdP A". Great! The user is authenticated and now we can check what roles/actions are authorized for that user. Now, I happen to know that this user is not associated with IdP "B", but let's say some malicious user gets into their system, creates a user for [email protected]. Now the compromised IdP posts a SAML token to me saying "Yep, this is [email protected], he's signed in over here and has claims for x, y, and z. Signed, IdP B". Since both IdPs are registered with me, the SP endpoint accepts both tokens. Maybe in some scenarios, that behavior is even desirable (if the user worked for two organizations for example). I'm just curious what other strategies might be used to keep users separate. I like your suggestions of including an IdP-specific SAML assertion but I guess a user-to-entityID mapping is the only other answer.
|