0

I want to validate a SessionSecurityToken issued by a STS. By validate, I mean certify that the token is not crafted and verity that the token is issued from the STS.

Conceptually, I know that if the STS encrypt (or sign) the token with it's private key, I could decrypt (or validate signature) with a public key.

From what I understand, the STS I am using (ThinkTecture Identity Server) uses a Symmetric Signing Key to sign to token.

The SessionSecurityToken I received contains a SecurityKeys property. What represent this SecurityKeys? MSDN documentation tells: "Gets the keys associated with this session. This is usually a single key."

Is it the SymmetricKey used by my STS? If so, it means that the symmetric key is not well protected, and if anybody gets this key, he could fake a token.

Is it the token signature? If so, how can I validate the signature (assuming that I have the symmetric key)?

Any other useful information to help me understand the way we validate a SessionSecurityToken?

Normand Bedard
  • 2,625
  • 2
  • 19
  • 22

1 Answers1

0

So first of all - STSes don't issue a session token. They issue (i guess you use WS-Fed) a SAML token. This token is signed with an X.509 certificate.

The relying party then takes the incoming SAML token and turns it into a session token and writes that to a cookie.

So why do you want to validate that? This is done automatically by the SAM.

leastprivilege
  • 18,196
  • 1
  • 34
  • 50
  • Yes I am using WS-Fed. I have a special architecture with three layers: 1- JavaScript WebApp 2- WebAPI 3- WCF (core logic) The Wcf layer is internal for all my logic (not exposed). The WebAPI layer is only a way to expose all the functionalities of my wcf core module to a Web RestAPI. There is no logic or validation is this layer. My JavaScript app is plugged on the WebAPI. What I want is my JavaScript application to be redirected on the STS, and push the "token" (which I was thinking was a SessionSecuriytToken), to the WebAPI that pushes it to the WCF, where all the validation occurs. – Normand Bedard Apr 26 '13 at 19:09
  • Right now, I push the SessionSecurityToken from the WebAPI to the WCF using the WCF headers in all request, so the WCF layer is able to do all the validations of the claims contained in the Principal inside the SessionSecurityToken. But to be able to push it to the WCF Layer, I get the SessionSecuritytoken from the WebAPI layer using FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken. – Normand Bedard Apr 26 '13 at 19:14
  • But from what you said, it seems that it is too late to do the validation in my WCf layer, it should occurs in my WebAPP, which break completely the way all the architecture works. – Normand Bedard Apr 26 '13 at 19:15
  • You should not ship around session security tokens. That's not what they are made for. You might have to revise your approach. – leastprivilege Apr 26 '13 at 19:22
  • Totally! The only way I see to solve my problem is to modify the STS to insert a special claim what contain the signature of all included claims. This way, in my WCF layer I could get that special claim and compute the signature of all other claims with a pre-shared key. This could certify the validity of all the claims, but, would be a totally ugly and hacky way to accomplish this. – Normand Bedard Apr 26 '13 at 19:27
  • I did not understand your problem (and I haven't tried to). But don't do that. There's certainly a better way. – leastprivilege Apr 26 '13 at 19:39
  • My design implies that all the validation occurs on a low-level layer near all my business logic, and not from the WebApp access point where all the federation/validation stuff typically occurs, so I am screwed. Anyway, I think I will need to use something more custom and flexible, without all the great benefits of WS-Fed. Thanks for you help. – Normand Bedard Apr 26 '13 at 19:45