SSO Adding claims to a social login (SAML WS-Fed)

Question

I'm trying to get my head around SSO concepts and how they fit to my situation, and I've got to the point where I'm a bit stuck. Assuming we use something like Azure AD, or Ping Identity or something along those lines, we want to enable social login (google account / facebook etc) - that is all fine. The bit I keep getting stuck on is how do I control the claims to attach to that identity?

Process (in my head) overview: - User logs in with google (facebook etc) account, they associate the google account with their 'legacy' account (i.e. link up their social login with their internal identifier that we as a business identify them as) what what ever that process is, does not matter for this discussion (i dont think).

Now when a user logs in with their social account, how do I perform the lookup of that mapping to their internal identifier to add it as a claim, and add the related other claim for that user based on information my organisation knows about them (e.g. If they are over 21, what 'level' of a member they are etc).

I get that if we had one RP using SSO, it as the RP could perform this logic, but we have the situation where we have several internal (and potentially externally managed) systems (4-5 currently) we want to tie together using SSO - which will rely on these claims for access / personalisation etc.

The closest I have seen to this is the concept of a RP-STS - which would effectively from what I could work out sit in front of Ping / AZ AD to form part of the chain, so so it can do the internal lookup and add additional claims as necessary - does that make sense as a concept? Is that the right approach?

I'm sure this can't be un-common - but i can't seem to find any good example / documentation around the full integration (plenty on just AZ AD / Ping etc) that we need. There must be off the shelf products that can do this? (We really dont want custom SSO implementation / components if possible)

Answer 1

The closest I have seen to this is the concept of a RP-STS - which would effectively from what I could work out sit in front of Ping / AZ AD to form part of the chain, so so it can do the internal lookup and add additional claims as necessary - does that make sense as a concept? Is that the right approach?

That is exactly the role of an RP-STS (or "Federation Provider" in some of the literature). It sits in between your apps and multiple "Identity Providers" and is usually responsible for 2 things:

1. Protocol transition (e.g. your app might be WS-Fed or SAML, but Facebook is OAuth2)
2. Claims transformation and enrichment (e.g. add, remove, transform claims based on some logic).

There are several implementations of this with various degrees of sophistication/flexibility, and trade-offs:

1. Azure Access Control Service can do #1 and (somewhat limited) #2. But it is unclear whether the service has any future or if it will be subsumed by Azure AD.
2. IdentityServer can do all. It is OSS so you "own" it (e.g. host, operate, customize, etc). It's a great implementation, used in production, written by experts (Dominick Baier & Brock Allen) and very flexible.
3. ADFS can do some (limited # of protocols, proprietary claim transformation language that is complex to debug, but works). You have to host ADFS yourself. This is a MSFT product.

The company I work for offers similar capabilities too.