Popular SSO protocols

[Andrew Engelbrecht]

Hello SSP mailing list,

My org is considering using SSP for our SSO needs. So far I've
investigated the SAML 2.0, CAS and OIDC protocols for communicating with
our existing Web services. We need CAS for legacy support, and
unfortunately ODIC doesn't meet our use case because we need strictly
enforced user names, and OIDC's protocol apparently doesn't support that
feature.

I checked the modules page, and see that PAPI and OAuth2 are also
options. Are there any protocols other than SAML 2.0 and CAS that I
should consider installing for greater compatibility with popular self
hosted Web services?

Thanks, : )
Andrew

[pra...@gmail.com]

Hi Andrew,

For standardized SSO protocols, SAML and OIDC would be the most prevalent.

There are a lot of non-standard variations of using OAUTH 2 for logging in, which can be handled by one of the modules.

I don't think you need to expand to other SSO protocols. I'd conjecture that the more esoteric the sso protocol the less security validation has been done to it.

- Patrick

[Peter Schober]

* Andrew Engelbrecht <and...@fsf.org> [2020-08-25 23:50]:

> we need strictly enforced user names, and OIDC's protocol apparently
> doesn't support that feature.

Could you share what exactly "strictly enforced user names" are and
how other protocols enable those?

-peter

[Andrew Engelbrecht]

Hello Peter,

The most common use case for OIDC is to allow users to log into your
site, using credentials from one of many different OIDC end points. To
make this possible, it's necessary that the user name on site A is not
guaranteed to be available on your site, since it may be in use by
another person who already logged in with site B. As a result, it only
makes sense for the user name provided by site A and B to merely be
suggestions, and are not guaranteed to be available.

In my use case, we want the user names to be mapped 1:1 between the
identity source and the client. So the question is whether we can make
it work if I control both the source and client (those aren't the
official terms).

I experimented with an OIDC client module in Drupal, and my memory is a
bit hazy since this was a while ago, but the closest thing I could find
was matching based on email address if there were existing accounts with
a name collision. The reason a collision could come up is if one
switches one of their sites, Drupal, or some other site, from CAS logins
to OIDC logins, so there are existing accounts on the system.

There may be ways to hack around that, but the protocol specifies that
that shouldn't be done:

"5.7. Claim Stability and Uniqueness

... Therefore, other Claims such as email, phone_number, and
preferred_username and MUST NOT be used as unique identifiers for the
End-User."

https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability

So my impression is that we can't rely upon great support for that use
case in most systems, because it breaks the spec. Even allowing
overrides based on email addresses is broken, if someone creates a new
account upstream and changes their email addresses, for instance.

I hope that answers your question.

Thanks,
Andrew

[Andrew Engelbrecht]

On 8/28/20 10:15 PM, pra...@gmail.com wrote:

> For standardized SSO protocols, SAML and OIDC would be the most prevalent.
> There are a lot of non-standard variations of using OAUTH 2 for logging in,
> which can be handled by one of the modules.
>
> I don't think you need to expand to other SSO protocols. I'd conjecture
> that the more esoteric the sso protocol the less security validation has
> been done to it.

Hello Patrick,

Do you consider OAUTH 2 to be an esoteric protocol, in the sense that
it's best avoided if possible?

Thanks, : )
Andrew

[Peter Schober]

* Andrew Engelbrecht <and...@fsf.org> [2020-09-01 00:26]:

> The most common use case for OIDC is to allow users to log into your
> site, using credentials from one of many different OIDC end points.

You control what OPs (OpenID Connect [Identity] Providers) you hook up
to your RPs (Service Providers, protected resources) and make
available for authentication. If you offer multiple, then yes, sure.
But you don't have to offer multiple servers/systems/providers to
subjects to log in from, of course. Neither with SAML 2.0 nor with OIDC.

> To make this possible, it's necessary that the user name on site A
> is not guaranteed to be available on your site, since it may be in
> use by another person who already logged in with site B. As a
> result, it only makes sense for the user name provided by site A and
> B to merely be suggestions, and are not guaranteed to be available.

I don't follow, but maybe that's because we have different views on
what a username is: Allowing logins from different OPs (or sites or
organisations or identity stores or identifier namespaces) necessarily
means you must either insist on the use of globally unique identifiers
from the start (so there is no potential for collision) or the RP must
qualify only-unique-within-each-OP identifiers with the OP/issuer
during at login time to /make/ them globally unique at the RP.

I.e., not-by-themselfs-globally-unique identifiers from identity silos
(such as the so-called "social identities" from Internet Monopolists)
would have to be qualified with the OP, either by the OP (in some part
of the protocol, I don't speak OIDC) or at the RP when reciving it.
Then 'foobar123' from Facebook becomes "foobar123 at facebook", in
whatever syntactical notation, e.g. the one we know from e-mail
addresses or kerberos subject principals, "foob...@facebook.com".

> In my use case, we want the user names to be mapped 1:1 between the
> identity source and the client. So the question is whether we can
> make it work if I control both the source and client (those aren't
> the official terms).

I don't think that changes anything I wrote above: Either all
identifiers are already globally unique across all "sources" (OPs, I
think) or the RP would have to make them globally unique by qualifying
the identifier with the issuer/OP/source.
If you control all parts, incl. all "sources" you may already have
ensured that there are no identifier collisions across all source
systems. In which case there'd be no potential for collisions at any
of your RPs, either.

Cheers,
-peter

[pra...@gmail.com]

I don't think it's esoteric. It is widely used by Google/Microsoft/etc to interact with their APIs. 

It's also not a SSO protocol by itself, so I'm not sure what you mean by avoiding it.

- Patrick 

[Roland Hedberg]

> On 1 Sep 2020, at 12:28, Peter Schober <peter....@univie.ac.at> wrote:
>
> * Andrew Engelbrecht <and...@fsf.org> [2020-09-01 00:26]:
>> The most common use case for OIDC is to allow users to log into your
>> site, using credentials from one of many different OIDC end points.
>
> You control what OPs (OpenID Connect [Identity] Providers) you hook up
> to your RPs (Service Providers, protected resources) and make
> available for authentication. If you offer multiple, then yes, sure.
> But you don't have to offer multiple servers/systems/providers to
> subjects to log in from, of course. Neither with SAML 2.0 nor with OIDC.
>
>> To make this possible, it's necessary that the user name on site A
>> is not guaranteed to be available on your site, since it may be in
>> use by another person who already logged in with site B. As a
>> result, it only makes sense for the user name provided by site A and
>> B to merely be suggestions, and are not guaranteed to be available.
>
> I don't follow, but maybe that's because we have different views on
> what a username is: Allowing logins from different OPs (or sites or
> organisations or identity stores or identifier namespaces) necessarily
> means you must either insist on the use of globally unique identifiers
> from the start (so there is no potential for collision) or the RP must
> qualify only-unique-within-each-OP identifiers with the OP/issuer
> during at login time to /make/ them globally unique at the RP.

It’s specified in the OIDC standard that the subject identifier returned from the OP
can only be made globally unique by adding the OP’s identifier.

Note: ’subject identifier’
This is not what you normally would call a user name.

There is support in the standard for letting the OP provide the same subject
identifier for a user to several RPs. There is absolutely nothing to make several OPs
use the same subject identifier for a specific user.

— Roland

[Peter Schober]

* Roland Hedberg <kust...@gmail.com> [2020-09-02 09:17]:

> > Allowing logins from different OPs (or sites or
> > organisations or identity stores or identifier namespaces) necessarily
> > means you must either insist on the use of globally unique identifiers
> > from the start (so there is no potential for collision) or the RP must
> > qualify only-unique-within-each-OP identifiers with the OP/issuer
> > during at login time to /make/ them globally unique at the RP.
>
> It’s specified in the OIDC standard that the subject identifier
> returned from the OP can only be made globally unique by adding the
> OP’s identifier.

OK, great (I think?) -- so, as I said above, either the OP already
releases globally unique values (which the RP then can use "as is",
without fear of collisions) or the RP can qualify them with the OP
(again, making them globally uniquie, avoiding collision).

Though if any standard identifier types don't fulfill my needs I'd use
custom identifiers/attribute/claims (as we've done with eduPerson,
SCHAC, etc. attributes for decades, at least in the academic sector).

-peter