For technical reasons we have implemented two different STS websites in our application. These STS issue tokens which are based on different certificates.
We have a main application and a subset application and each are configured to use and trust one of these STS websites.
Both applications use the Claim Type Name to set the users name at login, and this is then surfaced in the relying party applications UI.
My problem is that if I login to one STS, everything is fine. When I login to the other application/STS, the name surfaced in the UI from the first login is replaced with that of the second login.
I can only assume that as the STS's are using completely different certificates to sign the tokens they will be ignored by the relying parties unless configured to trust within the web.config. This is how I have set it up.
From debugging, everything seems to work fine. The correct STS to used and the correct certificate is used when creating the Token.
I can see that the existing FedAuth cookie grows when I login to the second application so the claims for both sessions are being added to the same cookie.
I would appreciate if someone can offer some suggestions as to how to make the tokens issued by the STS completely independent of each other.
Thanks very much,
What you are seeing is the correct behaviour, and both tokens are in fact different. If you hadn't add the 2nd STS in the config, the authentications against that STS might succeed, but they will be rejected by WIF, because they would come from a "non-trusted" source (the undeclared STS).
If you add the 2nd STS as a "trusted issuer", the WIF (in your app) wil happily accept its tokens. The Claim Type "name" is simply what is mapped to
It'd probably help if you explained a little bit more what is it that you want to do. What shoudl happen in your app when someone logs in with the 2nd STS?
The reason for this behaviour is that neither Relying Party had a name set for the authentication cookie, so they both used "FedAuth". By explicitly giving them different names to use for the cookie in the cookieHandler, the problem was fixed.
<microsoft.identityModel> <service> <federatedAuthentication> <wsFederation passiveRedirectEnabled="false" issuer="http://localhost:9006/App.AD_STS/" realm="http://localhost:6542/" requireHttps="false" /> <cookieHandler requireSsl="false" path="/" name="AD_STS" /> </federatedAuthentication>