Custom STS SSO failing

Question

I'm working on a roll-your-own Federation implementation. There are two RPs. SSO between the RPs does not work (erroneously). I suspect it has to do with the cookie that the STS is creating. The STS is writing a fedauth cookie for itself. From my understanding, it should be writing a Forms Authentication cookie?

When hitting the STS for the second time from the other RP I can see in the ClaimsPrincipal that IsAuthenticated=True, yet the user is prompted to login and not automatically redirected back to the RP.

It's worth noting that SSO did work previously, auto redirect and all, but the RPs on the load balancer couldn't share cookies as it was using the machine key (and no sticky sessions). I fixed this by implementing a custom SessionSecurityTokenHandler that utilizes the certificate (code below). It's at this point that the STS started writing FedAuth cookies and SSO started failing.

The sts token is being written with:

FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(token);

Token handler:

var sessionTransforms = new List<CookieTransform>(new CookieTransform[]
    {
        new DeflateCookieTransform(),
        new RsaEncryptionCookieTransform(federationConfiguration.ServiceCertificate),
        new RsaSignatureCookieTransform(federationConfiguration.ServiceCertificate)
    });
    var sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
federationConfiguration.IdentityConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);

score 0 · Answer 1 · answered Jul 18 '16 at 23:34

0

The STS writes its own cookie. It POSTs the security token to your application. Your application will typically respond by writing a session authentication cookie, which it will use until it expires (and then it goes back to the STS)

If you work in a web farm then there is an out of the box support for this using WIF configuration :

Of course, the machines in the web farm should then share the same machine key. You can of course use your own mechanism but that seldom makes sense.

Next, each RP should therefore write its own "session" cookie that proves your authentication. If two RP's live in the same domain then they should use a different cookie name.

answered Jul 18 '16 at 23:34

Willy Van den Driessche

1,619
15
23

Using the machine key is not necessary, we're using the same certificate on all machines. Each RP is writing its own cookie. That's all fine. My question was: Should the STS be writing a FedAuth cookie for itself? And: Why isn't the STS logging in automatically when being hit again from the other RPs? (Yes audience uris are correctly specified) – Swifty Jul 19 '16 at 05:42
It would help if I know which STS you are using. Normally, when you sign in, the STS writes a cookie in its own domain. This cookie makes sure you have single sign on for the next RP. This might be a session cookie in a normal scenario and a permanent cookie in the "remember me" scenario. The RP's are free to do what they want. In general, they will respond to the security token by writing a session security token in their own domain. When the next RP goes to the STS, the STS will send a security token for thát RP without showing any UI. That last behavior depends on the STS. – Willy Van den Driessche Jul 19 '16 at 08:24
Just one thing to add : In general it is not a good idea to share session security token cookies between relying parties. – Willy Van den Driessche Jul 19 '16 at 08:28
Its a custom STS built in-house. The STS does write its own fedauth cookie, it passes the security token to the RP which then writes the RP's fedauth cookie. When the second RP hits the STS, the user is prompted to log in again. If I inspect the ClaimsPrincipal at that point, I can see that the user is authenticated (before logging in for the second RP) – Swifty Jul 19 '16 at 11:50
Again, I assume that the cookies written by STS, RP1 and RP2 either have different names or live in other domains. As far as I can see, your STS has to react to the presence of its own cookie by not showing any UI but directly POST a security token to RP2. In that case the STS cookie acts as "credentials" for the user. We do the same (also custom STS) and write a random number in the STS cookie. That random number is stored in our database to authenticate that user. This "credential" expires after some period (some hours to a year) or when the user changes her password. – Willy Van den Driessche Jul 20 '16 at 17:00

Custom STS SSO failing

1 Answers1