Deploy CardSpace on your site without a SSL certificate
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=
‘https://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>https://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 https://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