We are considering ACS as our federated STS. We can configure our own custom STS as an IP-STS, as well as the "built-in" identity providers such as Facebook, Live and Google. The claims we get back are however rather "poor". The claims transformation in ACS only helps in very simple scenario's.
We are looking for a best-practice to handle the situation of "missing claims". We think we need to place a "decorating STS" in front of ACS. When ACS comes back with a security token, this decorator can "enrich" the security token with additional claims. If the claims are simply missing, it can put up some user interface to ask the user (once) to complete her profile. This way, regardless of where the user comes from, we have the claims the application requires. Is this a good idea ? What is the "best practice" in this case ? (ACS doesn't seem to allow for any programmatic extensions.)
2 Answers
I think the answer would really depend on the exact scenario. ACS is not meant to manage profiles and as such what it can, and should do, with regards to outgoing claims is limited more or less by design - it is a man-in-the-middle in all-but-one cases.
Apart from when managing service identities, it can only work on the input it receives from the identity provider and it does not have the remit of managing user profiles or anything similar.
With that in mind I think you really only have two reasonable options - either your identity provide provides more information, which can be passes through, and potentially transformed by, ACS or your application receives the basic identity from the IPs through ACS and manages its extended profiles.
I've written about the latter here
What you want is called an RP-STS and is quite straightforward to set up. Federation can be thought of a chain, in the ACS case this is typically RP -> ACS -> IdP, where token requests move left to right and tokens move right to left. In a federation chain, each entity is only explicitly aware of its neighbors. What you want instead is RP -> RP-STS -> ACS -> IdP. In fact, ACS can also be thought of as an RP-STS, in that it's neither an identity provider nor a relying party. You're just adding another link in the chain, which is OK because federation chains can be arbitrarily long.
Your RP-STS will have two primary actions:
- When the RP sends a sign-in request, package the details of this request (e.g. the original RP's realm and reply address, any RP context, etc.) in wctx and create a this sign-in request to ACS.
- When ACS sends a token back to the RP-STS, unpack the context, add any value needed (such as prompting the user for more details or looking up a profile) and then issue a new token with the added claims and any claims ACS issued that you want to keep.
What you're effectively doing in this case is outsourcing the authentication to Google/FB/etc. to ACS because you don't want to deal with those protocols, and then adding your own value after authentication is complete. From ACS's point of view, there is only one RP registered: your RP-STS. From your actual RP's perspective, there is only one identity provider: your RP-STS.
