I must have missed the memo on unencrypted tokens… will check with the OSIS crowd and report back – this will most likely temporarily break some Relying Parties (including mine). Oh, the wicked pace of progress 🙂
~ by Pamela on 28 May 08.
Posted in MS/AD/InfoCards/CardSpace
Ah that’s for the noSSL scenarios; which came on-stream as part of .NET 3.5
Barry Dorrans said this on 28 May 08 at 2:08 pm | Reply
That’s what I thought at first too – but apparently this has nothing to do with the HTTPS protocol — the wag site pictured above is an SSL site. It happens at my sites too, which are currently all HTTPS sites.
In fact, I would say that the HTTP case is the one place where an encrypted token should be mandatory, since the transport is in the clear…
Pamela said this on 28 May 08 at 2:25 pm | Reply
Ah but if it’s coming over HTTP there is no certificate; so what do you encrypt against?
And once we’re using managed cards all bets are off anyway; as an STS you don’t have to encrypt against the public SSL certificate, you could have a pre-agreed arrangement where you distribute client certificates and use those, or even ROT13 *grin*
Barry Dorrans said this on 28 May 08 at 10:26 pm | Reply
(Was this a managed card BTW? If it’s a managed card which audits, i.e. has RequiresAppliesTo then it’s up to the STS to encrypt, and that is optional)
Barry Dorrans said this on 28 May 08 at 10:27 pm | Reply
Hi Pamela – this came up at I3. I originally misconfigured our STS to not encrypt tokens. Most RPs worked ok, but some failed ( all of yours ). I looked back at the spec and unencrypted tokens seem to be allowed, so I left the STS as is, since it looked like a good test.
Pat Patterson said this on 28 May 08 at 11:00 pm | Reply
Re: mandatory encryption in the HTTP case. I respectfully disagree 🙂
Vittorio said this on 28 May 08 at 11:32 pm | Reply
I had originally just assumed that it was tied to the web protocol used, ie if the RP uses SSL, they get an encrypted token back, and if the RP uses NoSSL, then all bets were off.
From the discussion on the OSIS list, it sounds like an RP needs to handle both possibilities for token encryption, regardless of whether the connection itself is encrypted. After that, it would be the administrator’s choice to reject certain types of tokens if it was a problem.
Pamela said this on 29 May 08 at 8:56 am | Reply
Vittorio: yeah, look at me, getting all demanding 🙂
I’d like to think that an RP *could* demand some level of encryption even though there is no SSL channel. To say they *must* do so is just silly.
Maybe I’ll just get NoSSL working first, before I worry about message-level encryption schemes 🙂
Pamela said this on 29 May 08 at 9:34 am | Reply
Oh its rather fun.
If you are an auditing STS it’s up to you to encrypt using the endpoint information (or anything else you decide). If you are a non-auditing STS you cannot, so a plain text token is sent back to the selector. The selector then encrypts against the public key of the RP SSL certificate if there is one.
I blogged this in February 🙂
Barry Dorrans said this on 29 May 08 at 9:44 am | Reply
Oh and it’s a function of the managed card to decide if it supports NoSSL. If you issue a managed card with a RequireStrongRecipientIdentity parameter it won’t even light up in the selector if a non-SSL site is triggering card selection.
Of course it’s always best to check on the STS, just in case a selector got it wrong.
The other point to note is how then is a token tied to an RP in a no SSL/No encryption case; it has to be a site specific ID, either reflecting the client pseudonym as a PPID or constructing a site specific one of your own.
Barry Dorrans said this on 29 May 08 at 9:48 am | Reply
Fill in your details below or click an icon to log in:
You are commenting using your WordPress.com account. ( Log Out / Change )
You are commenting using your Twitter account. ( Log Out / Change )
You are commenting using your Facebook account. ( Log Out / Change )
You are commenting using your Google+ account. ( Log Out / Change )
Connecting to %s
Notify me of new comments via email.
Blog at WordPress.com.