All the bits to employ CardSpace without an SSL certificate are now available

CardSpaceBlog — Fri, 26 Oct 2007 09:24:00 GMT

Hi, my name is Tariq Sharif and I am a program manager in the CardSpace team. After we released CardSpace V1 we received feedback from hobbyists, early technology adapters and site owners that getting/setting up a SSL certificate is hard and it is not needed for some set of their scenario and that this is blocking them from accepting information cards on their sites. Based on this feedback, the feature team decided to remove this requirement for the .Net Framework 3.5 release.

In order to invoke Cardspace from a page that does not have an SSL connection you need two updated components. First you will need to install an updated browser specific extension that will work at an HTTP site. You can download the IE extension from here or if you have IE7 you probably already have it as part of the October security update. Second you will need to install an updated version of Cardspace that does the right thing when a website, the relying party, does not have a certificate. Latest version of Cardspace can be downloaded as part of .Net Framework 3.5.

You can read more technical details about this new functionally here in this post that Ruchi made a couple of weeks ago. Please feel free to drop us any comments on this, as we are always looking for feedback to help us refine this emerging technology.

Thanks,

Tariq Sharif

Program Manager

Deploy CardSpace on your site without a SSL certificate

CardSpaceBlog — Tue, 25 Sep 2007 03:36:00 GMT

CardSpace in .Net Framework 3.0 required that sites deploying CardSpace always have a SSL certificate. This meant that every site that wanted to use CardSpace was forced to deploy an https site.

Based on customer feedback, we have decided to relax this requirement for the next release of CardSpace (currently available in .NET Framework 3.5 Beta 2). We realize that there are some sites like blogs which would like to use CardSpace, but consider the SSL requirement to be a deployment blocker. Now, if you have a website that you want to add CardSpace support to, all you need to do is add the object tag to the page and you are done.

In addition to requiring .Net Framework 3.5 beta 2 or later, a new version of icardie.dll is required to use this new feature. This will ship with Vista SP1 and an upcoming update to IE7.

CardSpace does behave differently for http vs. https sites. When CardSpace is invoked from an http site, CardSpace will inform the user about the lack of an SSL connection and the security implication of this. (Also, note the new streamlined look of this window)

In addition, managed card issuers can decide if the card they issued can be used on sites that do not support SSL. This can be done by adding the following element to the .crd file.

<wsid:RequireStrongRecipientIdentity xmlns:wsid= ‘http://schemas.xmlsoap.org/ws/2007/01/identity’>

If this element is specified then the card can only be used on a site that has a SSL certificate. The card will not ‘light up’ when the user is on an http site. A point to be noted is that cards that were issued for last release of CardSpace will light up on http sites as they will lack this new element. In that case, the IP STS can make a decision on whether to release a token based on the identity of the recipient sent in the RST message. Another feature that was added for this release is the support for custom soap faults (next blog entry will have details on that feature) and that can be leveraged to provide the user with appropriate error information. Similarly, if a .crd file with this element is imported into the last release of CardSpace, it will be ignored.

Some other differences on an http site are:

1) PPID value is different as no certificate is available. The method used to calculate the PPID is the same as described in the Identity Selector Interoperability Profile. The only difference lies in the calculation of the RP identifier. The RP Identifier is calculated as follows

a. OrgIdString = fully qualified DNS host name or the IP address of the server specified in the URI of the site.

b. Encode all the characters in OrgIdString into a sequence of bytes, call it OrgIdBytes, using Unicode encoding (UTF-16LE with no byte order mark).

c. Hash OrgIdBytes using the SHA256 hash function, and use the resulting value as the RP identifier.

RP identifier = SHA256 (OrgIdBytes)

2) For an auditing STS, only the URL of the site is sent to the IP STS as identity information for the relying party. As described in the Identity Selector Interoperability Profile ( Section 4.3.3), if no wsp:AppliesTo is specified in the relying party’s token policy and the IPSTS requires it, the following will be sent for a http site

<wst:RequestSecurityToken>

<wsp:AppliesTo>

<wsa:EndpointReference>

<wsa:Address>http://ip.fabrikam.com</wsa:Address> </wsa:EndpointReference>

</wsp:AppliesTo> ...

</wst:RequestSecurityToken>

Though a certificate is not sent to the IP STS, the token returned by the STS can still be encrypted if the identity provider has a pre-existing relationship with the RP and has mutually agreed on the use of a known encryption key.

3) Self issued tokens are not encrypted. Because the token is unencrypted, the only change most token processing libraries require is to skip the decryption step, the rest of the token remains unchanged. The token processing sample at http://cardspace.netfx3.com/ will be updated with this change.

4) Though the self issued tokens are not encrypted they are still signed as described in Section 8 in Identity Selector Interoperability Profile

Let us know if you have questions or feedback.

Ruchi

Software Design Engineer - CardSpace Team

“Geneva” Team Blog : HTTP

All the bits to employ CardSpace without an SSL certificate are now available

Deploy CardSpace on your site without a SSL certificate