Add requirement about segmentation of SSO identities

[randomstuff]

In the context of OpenID Connect, I was wondering whether a requirement mandating that user identities from different IdPs are properly separated i.e. that a IdP cannot spoof a user from another IdP. This is actually relevant for any SSOs and might go into V2.

Original wording:

Verify that, if multiple identity providers are used by a RP, the identity of a user from an identity provider cannot be spoofed by another identity provider (by using the same user identifier).

Alternative wording:

Verify that, if multiple identity providers are used by a relying party, a malicious identity provider cannot login as users from another identity provider (eg. by using the same user identifier).

The wording should reject unintended/malicious spoofing of user identities but still allow cases where the sharing of user identities between different IdP is intended / by design.

[TobiasAhnoff]

I was thinking that this is not limited to users, it could also be an issue for machine-to-machine (OAuth client credentials), all scenarios where the RP use multiple identity providers (issuers).

Maybe have something that not only for OIDC, or do we already address this in other issues?

Verify that, if multiple identity providers are used by a RP, the identity from one identity provider cannot be spoofed by another identity provider (by using the same user identifier).

or, from the JWT spec "The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

Verify that, if multiple identity providers are used by a RP, the identity MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

[randomstuff]

Maybe have something that not only for OIDC, or do we already address this in other issues?

Yes, that's why I was suggesting it should go into the V2 chapter (instead of the OIDC one) and was avoiding OIDC-specific terms. This would equally apply other user type of user identity sources (SAML, LDAP, CAS, etc.).

[elarlang]

Steps here:

• formulate requirement text
• check we don't have duplicates in V51
• think about suitable section

[elarlang]

ping @tghosth as it is in V2 area

[tghosth]

I think this is a great idea and important for V2.

Just so I understand, do I correctly understand the theoretical attack scenario:

I have a facemorphing app. People can take photos of their face and store them. The app offers both Facebook and Twitter social login.

A user (Alice) has an a account [email protected] with Facebook and signs up for my app. They then start using my app normally.

An attacker (Mallory) registers a Twitter account using the email address [email protected]. The owner of Twitter fired the team that was supposed to implement email verification so the attacker is able to successfully register this account.

Mallory then logs into my app using Twitter social login and is logged into Alice's account because the email account matches.

1. Is this correct?
2. @randomstuff do we definitely not already have a requirement like this in V2?

[elarlang]

2. @randomstuff do we definitely not already have a requirement like this in V2?

This check is something we should do. We don't have any SSO topics covered in V2.

[jmanico]

How about “you can only use one SSO Identity for public federation” (public federation is when you can use any public identity provider at registration). These public OIDC service's tend to be weak when it comes to registration, that’s just the nature of public federation/OIDC. (In an enterprise, the registration would be much more detailed and use a corporate IdP.) So how about, once I use Twitter, Facebook can no longer be used or similar?

[tghosth]

How about “you can only use one SSO Identity for public federation” (public federation is when you can use any public identity provider at registration).

These public OIDC service's tend to be weak when it comes to registration, that’s just the nature of public federation/OIDC. (In an enterprise, the registration would be much more detailed and use a corporate IdP.)

So how about, once I use Twitter, Facebook can no longer be used or similar?

@jmanico my concern is that we are mandating only one way of solving the problem here, if there is a use case where they need to support multiple social identities or something then this becomes a problem

This check is something we should do. We don't have any SSO topics covered in V2.

@elarlang have I understood the requirement correctly here?: #2150 (comment)

[jmanico]

@jmanico my concern is that we are mandating only one way of solving the problem here, if there is a use case where they need to support multiple social identities or something then this becomes a problem

In most cases, only one login provided is needed and a "single SSO" policy is really good for security and relatively easy to enforce. It's admittedly possible but very rare that different social logins are needed for the same user. Very rare. How about we have a requirement forcing the initial social login to take precedence (and blocks a second social login) - unless multiple social identities are necessary?

[tghosth]

@jmanico my concern is that we are mandating only one way of solving the problem here, if there is a use case where they need to support multiple social identities or something then this becomes a problem

In most cases, only one login provided is needed and a "single SSO" policy is really good for security and relatively easy to enforce. It's admittedly possible but very rare that different social logins are needed for the same user. Very rare. How about we have a requirement forcing the initial social login to take precedence (and blocks a second social login) - unless multiple social identities are necessary?

My preference is to focus on the goal, i.e. only allow social login where the registration clearly pairs the email address with the service it came from

[randomstuff]

My preference is to focus on the goal, i.e. only allow social login where the registration clearly pairs the email address with the service it came from

I would say ideally the account identifier should be the (issuer, sub) pair(when using the OIDC terminology or (idp_id, idp_user_id) in general and using email address as user identifier should be frown upon (for many reasons). I don't know how it's usually implemented in practice.

[randomstuff]

A user (Alice) has an a account [email protected] with Facebook and signs up for my app. They then start using my app normally.

An attacker (Mallory) registers a Twitter account using the email address [email protected]. The owner of Twitter fired the team that was supposed to implement email verification so the attacker is able to successfully register this account.

Mallory then logs into my app using Twitter social login and is logged into Alice's account because the email account matches.

Yes, this was the kind of attack I was thinking about but I was more thinking about the case where the application would actually using the OIDC "sub" claim as user ID without storing the issuer as well. Then Twitter could theoretically spoof Alice's user account by just using the same user ID (of course, this assumes that Twitter somehow managed to learn the Alice's "sub" ).

So how about, once I use Twitter, Facebook can no longer be used or similar?

Let's Alice has an account on MyTrustedFileStorage tied to Facebook's IdP:

• If later on, Alice explicitly binds this existing account to her GZ (a fictional social network) account, that's fine. It's Alice's choice to trust GZ.
• If however, this binding is done automatically based on some matching claims between the two IdPs, I would find it very dubious because Alice may not trust GZ at all or may not even know GZ exists.

I'm taking this example to illustrate that there might be trust and even geopolitical issues at hand here (where one IdP could be coerced into spoofing an identity, for example if this IdP is located in a foreign country which might have interests in accessing Alice's data).

[randomstuff]

I think this is a great idea and important for V2.

@tghosth, Yes I think it would make sense to have a dedicated section for "Federated auth / SSO" in V2. There are probably other requirements which could be added there. (Then the question is how to avoid duplication with the OIDC chapter and how to decide what should be a general SSO requirement and what should be a OIDC specific requirement).

[tghosth]

I would say ideally the account identifier should be the (issuer, sub) pair(when using the OIDC terminology or (idp_id, idp_user_id) in general and using email address as user identifier should be frown upon (for many reasons). I don't know how it's usually implemented in practice.

I think IDP ID and User ID is probably the most neutral.

What do we think about:

"Verify that, if the application supports multiple identity providers (IDPs), it registers the user with a combination of IDP ID and the user's ID in the IDP so that the user's identity cannot be spoofed via another supported identity provider (by using the same user identifier)."

[tghosth]

@randomstuff can I get feedback on my suggested wording?

"Verify that, if the application supports multiple identity providers (IDPs), it registers the user with a combination of IDP ID and the user's ID in the IDP so that the user's identity cannot be spoofed via another supported identity provider (by using the same user identifier)."

[randomstuff]

@tghosth. LGTM but I am wondering if the requirement should be that detailed. In some specific cases, you might want have some more relaxed constraint.

For example, you might have two IdPs with some trust relationship and some shared user identifier. In this case, it might be OK if they share the same ID space.

I attempted to cover this case (implicitly) in my initial wording (« the identity of a user from an identity provider cannot be spoofed by another identity provider »), in the sense that if this user ID collision is desired/specified/by design, it is OK.

Let's take an illustration:

• Pro Santé Connect is a OIDC healthcare IdP for healthcare practitioners which uses a custom claim (not "sub") to transmit the national healthcare practitioners identifier.
• An regional/institutional IdP could provide its own identification service using the same national healthcare practitioner ID.
• A local regional/institutional application might decide to trust this regional/institional IdP and the national IdP. It would be OK (and expected) that the user would be able to login through either of them and obtain the same application account.

[tghosth]

Ok so basically:

"Verify that, if the application supports multiple identity providers (IDPs), the user's identity cannot be spoofed via another supported identity provider (by using the same user identifier)."

@randomstuff

[randomstuff]

@tghosth, Note that I liked the more explicit description of "IdP1 can attempt spoof the user id from IdP2".

Anyone else has an opinion on this? @jmanico @elarlang

Can we combine both formulations with something like:

Verify that, if the application supports multiple identity providers (IDPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). Usually, the application should register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IDP.

[jmanico]

I like the more explicit explanation myself.

[tghosth]

@randomstuff can you PR into a new section in V2 called Federated Authentication

[randomstuff]

I made a PR with my latest version but I'm not sure we are agreeing on this one…