Compartir a través de

Deploy CardSpace on your site without a SSL certificate

  • Artículo

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)

 

No SSL screenshot

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

Comments

  • Anonymous
    September 24, 2007
    In short: I discuss a new feature, introduced by the .NET framework 3.5 and by a (future) update of IE,
  • Anonymous
    September 25, 2007
    Great to hear that you are listening to our feedback :). Thanks!
  • Anonymous
    September 26, 2007
    "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."Why require mutual agreement? Why not allow the specification of a public key from the relaying party within the object tag, or a pointer in that tag to a key file? That could also be used by an STS to generate a PPID in the same way that auditing STSes could use the requesting URL to generate a realm and produce a unique realm specific ID.
  • Anonymous
    October 05, 2007
    I am giving a presentation on CardSpace and OpenId topics at the Richmond Code Camp tomorrow. Here are
  • Anonymous
    October 25, 2007
    Hi, my name is Tariq Sharif and I am a program manager in the CardSpace team. After we released CardSpace
  • Anonymous
    October 29, 2007
    New in CardSpace with Fx 3.5
  • Anonymous
    November 20, 2007
    As part of preparing for the User-Centric Identity Interop event last month, the team I’m on, Federated
  • Anonymous
    November 20, 2007
    As part of preparing for the User-Centric Identity Interop event last month, the team I’m on, Federated
  • Anonymous
    November 20, 2007
    CardSpace: Behind The Code has this entry: As part of preparing for the User-Centric Identity Interop
  • Anonymous
    December 17, 2007
    A useful, yet sparsely documented feature of Windows CardSpace is its support for resource side Security
  • Anonymous
    December 17, 2007
    A useful, yet sparsely documented feature of Windows CardSpace is its support for resource side Security
  • Anonymous
    March 20, 2008
    One problem with the original version of CardSpace was that it seemed to reject some legitimate SSL sites,