ComponentSpace

Forums



Segregating users of separate identity providers


Segregating users of separate identity providers

Author
Message
CarbonJunky
CarbonJunky
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 17
Hello,

As a service provider we want to be able to be configured with multiple Identity Providers (from different client organizations), but we want to make absolutely sure that [Identity Provider A] can't go rogue and start sending SAML tokens to authenticate a user from [Identity Provider B].

We naively expected that we could use the domain of the Partner Name to do this, matching that against the user. In practice this has proved useless since so many organizations now use an IaaS provider like Microsoft or Okta to run their SSO-- in which case the Partner Name imported in from the XML metadata tells us nothing about which client we're talking to. It's typically just the service plus a UUID/GUID like:

https://sts.windows.net/a4d56353-5117-4d6c-8cd9-b805fcf1561c/
(not a real example of course)

Is there a separate internal name or property tag we can use? What would you suggest in this scenario?

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
I'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.

Regards
ComponentSpace Development
CarbonJunky
CarbonJunky
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 17
ComponentSpace - 7/16/2020
I'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.



ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
SAMLServiceProvider.ReceiveSSO returns the partner name of the IdP. Your can determine if there's no [email protected] associated with IdP B and reject the SSO attempt.

However, let's suppose [email protected] is a legitimate user at the compromised IdP B. There isn't a way to identify this as a compromised SSO.

Ultimately, there's a trust relationship between the IdP and SP. You can perform certain checks at the SP but if the IdP is compromised your SP potentially is compromised as well. That's why the private keys and the websites in general need to be kept secure.  

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 4 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search