This is new!
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 :)
10 Responses to “This is new!” |
|
Ah that’s for the noSSL scenarios; which came on-stream as part of .NET 3.5
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…
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*
(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)
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.
Hi Pamela,
Re: mandatory encryption in the HTTP case. I respectfully disagree :-)
http://blogs.msdn.com/vbertocci/archive/2007/09/25/windows-cardspace-will-work-without-https-too.aspx
cheers
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.
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 :)
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 :)
http://idunno.org/archive/2008/02/18/information-card-encryption-and-being-an-auditing-sts.aspx
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.