“Geneva” Team Blog : CardSpace

CardSpace Geneva Beta 2 Samples Package

CardSpaceBlog — Tue, 28 Jul 2009 21:08:00 GMT

With the release of Beta 2 comes a set of samples specifically targeted towards CardSpace developers. Whether you are a web developer or a C++ programmer, you are sure to learn something new in our CardSpace Geneva Beta 2 Samples.

The samples pack covers three broad areas:

· A series of incremental web page samples showing how to invoke CardSpace, culminating in a sample that shows error handling and progress spinners for long-running operations like policy and token retrieval.

· A sample that shows using Geneva Framework’s WSFederationAuthenticationModule to protect a web site with CardSpace credentials.

· A sample for VC++ programmers that demonstrates CardSpace’s API for native programs. If you have wanted to include the CardTile in your own program or browser extension, this is for you!

To install the samples, just unzip them and follow the instructions in the included readme file. Enjoy! If you have any feedback, please share it in the forums.

Silent Information Card Provisioning

CardSpaceBlog — Mon, 15 Jun 2009 20:51:00 GMT

One obstacle that administrators looking to deploy information cards in an enterprise will inevitably face is getting information cards to their users. Nobody wants to have to send an email to their users saying that in order to access a web service, they’ll need to go to an issuance website and download an information card. Things should just work. With that in mind, the “Geneva” Server and CardSpace teams created Silent Card Provisioning, a feature that uses Group Policy to deploy information cards to domain users automatically.

Step by Step

Setting up Silent Card Provisioning is very simple. In the “Geneva” Server UI, select your information card and choose “Save Group Policy Template Files.” This will save group policy files called IdentitySelectorBaseGPTemplate and AutoCardProvisioningGPTemplate. The .adm versions of these files are needed for Windows Server 2003 domain controllers, while the .admx and .adml are for use in Windows Server 2008. For more details and a step-by-step guide to setting up silent card provisioning, see this link.

“Geneva” Server creates the necessary group policy templates for you.

Once the group policy is set on the domain controller, domain users with CardSpace “Geneva” will automatically connect to the server, download and install the card. This process happens silently and the user doesn’t have to know or worry about it. If anything about the card, such as the image or authentication types, is changed on the Server, CardSpace will automatically pick up those changes. If the card is disabled on the Server, CardSpace will delete it from client machines. This means that once CardSpace is installed, the user doesn’t have to do anything to get the cards they need.

Tips and tricks

· This feature integrates well with Card Usage Policy. By setting a card to be silently provisioned and automatically used, administrators can really streamline their user experience.

· The group policy template files specify the location of the Geneva Server, the issuer name, and the time interval to check for card updates. This interval is set to two days by default but can be made longer or shorter if necessary. In addition to updating at this interval, users will have their cards updated each time they log on.

· The easiest way to ensure that a client machine gets its group policy and cards updated right away is to log off and log back on. For testing, the following commands run from an administrative command prompt will also update a client’s card(s):

o GpUpdate /force

o "%PROGRAMFILES%\Windows CardSpace\bin\CSHelper.exe" /provision

Hopefully this feature will streamline your experience with Geneva in the enterprise and we look forward to hearing your feedback.

Oren Melzer
Software Development Engineer
“Geneva” Team

Enterprise Policy for Zero-click Sign-in Using Information Cards

CardSpaceBlog — Tue, 09 Jun 2009 20:08:00 GMT

Reducing your login steps one click at a time

One of the major goals of CardSpace “Geneva” is to streamline the login process and make it as quick and easy to understand as possible. In the first beta, as Oren outlines in his post, by building the card selector within the Windows-integrated Credential UI dialog, we provide a minimalistic login interface that has a familiar feel among Windows users. Also, the CardTile web control that Colin describes here uses the card image to quickly show the user the state of their login. For Beta 2 we’ve taken this streamlining one step further by introducing a group policy-based Card Usage Policy feature, which allows an administrator to designate Information Cards for automatic submission. This new feature was designed to walk hand-in-hand with the new Automatic Card Provisioning feature.

How Jerry the domain administrator can pick out cards for his users automatically

Let’s suppose Jerry, a domain administrator at Contoso, has provisioned Contoso Kerberos backed Information Cards to all members of his domain. Jerry has also built a SharePoint site that employees can log into using their new Contoso cards. When users login for the first time, they will be prompted with the CardSpace selector. Normally, the selector is designed to help the user make informed decisions about how they use their issued identities. However, in this case the card selection decision has already been made by the Jerry the Administrator. The Card Usage Policy feature allows Jerry to set up a domain policy that directs the CardSpace clients on his domain to use the provisioned cards automatically at his SharePoint site. With the policy in place, when a user browses to Jerry’s application the CardTile login control automatically finds the Contoso provisioned card in the user’s store and displays that card’s image on the login page. The user notices that an identity has already been picked out for them; all they have to do is click once and they’re immediately logged in without being prompted with a card selector.

What constitutes a Card Usage Policy

The Card Usage Policy feature makes use of the new ic09:CardType element that was recently incorporated into to the OASIS Identity Metasystem Interoperability Specification Version 1.1. Any card that is issued with the new CardType element can be added to an automatic card selection policy. The CardType serves as a card classification mechanism and it is a URI (e.g. a GUID with urn:GUID: prefix.) The CardType is not unique to a specific Information Card and all cards that are issued from the same source or for the same purpose will typically share a common CardType. A Card Usage Policy is made up of a set of CardTypes. Each CardType can be associated with a list of target applications to which it can be used. Jerry uses the Windows Group Policy Editor snap-in to configure the card selection policy he wishes to have pushed to his domain joined users. For a step-by-step guide on how to do this, please see the section Configuring "Geneva" Server to Issue Information Cards in the Geneva Server SbS Guide.

Application patterns and hostname wildcards in a Card Usage Policy

A Card Usage Policy is mapped to a web application using an application pattern, which is in the simplest sense a subset of the full URL of the application’s login page. Jerry’s application login page is hosted at jerry.contoso.com/apps/sharepoint/Login.aspx, so to match his provisioned Information Cards to his application Jerry enters the host name “jerry.contoso.com”. Jerry can make his policy more specific by including the application path. For example, “jerry.contoso.com/apps” will match to all login pages hosted under the “apps” path. The path can be as specific or generic as Jerry wants, but it’s important to note that a card policy will apply to anything hosted under the path of a given application pattern. Jerry can also make the pattern more generic by replacing the leftmost dot delimited components of the hostname with wildcards. Let’s suppose Jerry’s colleague Amanda hosts a Contoso claims enabled application at amanda.contoso.com/reports/Login.aspx, and she wants to be included in Jerry’s Card Usage Policy. Jerry can include Amanda’s application by changing his application pattern to “*.contoso.com”. While handy, the application path wildcard comes with a few restrictions. It can only be included in the hostname portion of an application pattern, and the wildcard must always compose the leftmost piece of a dot delimited hostname. For example, patterns such as “www.*.contoso.com” or “*ntoso.com” will not work.

If you have any feedback or questions about the new Card Usage Policy feature, please check out the Geneva forum.

Andrew Lavers

Software Development Engineer in Test

CardSpace “Geneva”

What’s New in Geneva Beta 2

CardSpaceBlog — Tue, 12 May 2009 02:52:00 GMT

As announced at TechEd, Geneva has just released its Beta 2 bits! These are now available for download from here.

There is a lot that is new and updated in Beta 2! Here is a list of some of the things that you will be able to try out and give us feedback on. For additional details on each of these and more, see the release notes included with the Beta 2 package.

“Geneva” Server

· New rules engine for authoring claims transformation policies

· Ability to read attributes from AD, AD LDS, and SQL out of the box, plus pluggable provider model to enable access to other attributes stores

· Group policy-based Information Card provisioning for CardSpace “Geneva” clients

· Support for SAML 2.0 SP-Lite

· Proxy to enable authentication for users on the Internet when Geneva Server is on the intranet

· Scale out via farm and load balancer topology

· Powershell commandlets

· Support for AD RMS

· Utility for federating with the Microsoft Federation Gateway

“Geneva” Framework – IDFX

· Enhanced FedUtil Tool with local STS for easy offline development

· New Visual Studio templates for building claims-aware web applications, web services, and security token services

· Support for SharePoint 2007

· Revised token handlers

· Revised federation authentication module

· New Claims Authorization Manager API

· Updated config support

CardSpace

· Support for Group Policy-based Information Card provisioning.

· Updated management UI

· Updated card tile

· Group Policy-based way for administrator to make card selection decisions for specific sites

Improved provisioning of X509-backed cards
Compatible with most existing managed cards

We are very excited to be able to deliver these bits to you, and to hear your feedback. Please send any technical questions about Geneva to the product team via our forum or support email address. We will continue to announce updates to Geneva on our website and here on our team blog.

Backing a Managed Card with Alternate Credentials

CardSpaceBlog — Tue, 20 May 2008 02:55:00 GMT

When a Managed Card is used, the user must authenticate to the identity provider (IP), in order to get a token. The choices of authentication type are username/password, Kerberos, X509 certificate or a Self-Issued card. Each authentication type offers its own advantages and disadvantages.

· Usernames and passwords are easy to deploy, and users are familiar with them, but because they employ shared secrets they are also subject to social engineering attacks.

· Kerberos is great if your users are at work and using a card to access a federation partner’s site or web service, or accessing internal services that run on other platforms and usually can’t leverage their Windows identity. Since the user doesn’t need to enter extra credential info when they use the card, it requires little user interaction. The downside of Kerberos is that it doesn’t work well for many usage scenarios, such as when the user isn’t at work.

· X509 certificate backed cards can offer strong security, so are a good choice in high value scenarios. However the scenario needs to be of high enough value to justify the distributing and managing soft certificates or smart cards.

· Self-issued backed cards offer a streamlined experience since using them doesn’t require extra user interaction (though the user can choose to PIN protect their self-issued card). Of course, the self-issued card is stored on the machines it is used on, so it is probably not a good idea to use self-issued cards on a less trustworthy machine. (Does your friend really run an up-to-date virus scanner on his/her home machine?)

Those are the choices for picking a single authentication method. But what about cases where it could be useful to have a single card that can support different authentication methods? An example scenario is one where a user has a card on her laptop, which when she is at work and uses Kerberos, and when she is not at work uses X509 (or some other authentication method).

Specifying alternate authentication methods is fairly straightforward – at least as straightforward as a single authentication method. Alternate authentication methods are specified by including multiple <TokenService> elements in the Managed Card (.crd) file, were each token service can use a different authentication method. Details of this can be found the Identity Selector Interoperability Profile (Section 4.1.1.2).

It is important to note that the Token Services appear in decreasing order of preference. CardSpace uses this order to determine the sequence with which it will attempt to use the token services. CardSpace will first try to retrieve the policy using the metadata location URL from the first token service endpoint in the .crd file. If policy cannot be retrieved from the metadata location, or if the policy does not contain an entry for the specified token service, CardSpace will fail over to the next token service defined in the .crd file.

<ic:TokenServiceList>

<ic:TokenService>

<Address>http://contoso.com/kerb/sts</Address>

<wsx:MetadataSection>

<wsx:MetadataReference>

<Address>https://contoso.com/kerb/sts/Mex</Address>

</wsx:MetadataReference>

</wsx:MetadataSection>

</Metadata>

</EndpointReference>

<ic:UserCredential>

<ic:KerberosV5Credential/>

</ic:UserCredential>

</ic:TokenService>

<ic:TokenService>

<Address>https://fabrikam.com/X509/sts</Address>

<wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns="">

<wsx:MetadataReference>

<Address>https://fabrikam.com/STS/mex</Address>

</wsx:MetadataReference>

</wsx:MetadataSection>

</Metadata>

</EndpointReference>

<ic:UserCredential>

<ic:X509V3Credential>

<ds:X509Data>

<wsse:KeyIdentifier

ValueType="http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.1#ThumbprintSHA1"

EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"

xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

OdiGsVrqbay3mn6BAjiHontnV1U=

</wsse:KeyIdentifier>

</ds:X509Data>

</ic:X509V3Credential>

</ic:UserCredential>

</ic:TokenService>

(Figure 1)

CardSpace follows this same algorithm for each endpoint: first connect to the metadata endpoint, then retrieve policy for the specific token service endpoint.

For an example, suppose the metadata endpoint for the first service shown in Figure 1 is unavailable, and the metadata endpoint for the second token service does not contain policy for the STS endpoint. In that case, CardSpace will first try to retrieve the policy from the metadata location https://contoso.com/kerb/sts/Mex. Since that URL is unavailable, CardSpace will fail over to the next TokenService element, and retrieve the policy from https://fabrikam.com/STS/mex. However, since in this example, policy is returned, but does not contain information for the token service endpoint https://fabrikam.com/X509/sts, CardSpace will move to the next TokenService. This process continues until the policy is successfully retrieved for a token service, or there are no more token services to try. If the policy is retrieved for a token service, but the token service is not available, no fail-over occurs, at which point CardSpace will show an error to the user.

Now back to the example using Kerberos at work and X509 from home. This can be accomplished with CardSpace by specifying two token services in the .crd file. The first of the endpoints uses Kerberos authentication. The metadata endpoint for the Kerberos token service can be made available only from a machine using the corporate network. Fail over to the x509 endpoint will then occur when the user is not at work.

Let me know if there are questions or comments on how this works. Hopefully this is useful for some more advanced Managed Card scenarios. To learn more I recommend reading the Identity Selector Interoperability Profile, as well as chapter 3 of ‘Understanding Windows CardSpace’ . In the spirit of full disclosure, I’m co-author on the book so have been hesitant to self promote, but I’m mentioning it here as I really think it is relevant, and sincerely hope others find it useful.

Thanks,

Caleb

CardSpace Certificate Chain Validation Issue with Intermediate Certificates

CardSpaceBlog — Fri, 21 Mar 2008 09:46:36 GMT

One problem with the original version of CardSpace was that it seemed to reject some legitimate SSL sites, but like all tricky bugs, it didn’t happen consistently enough to be caught in the first release. What was going on was that sometimes CardSpace couldn’t validate the intermediate certificates in the certificate chain because of a disconnect with the browser’s certificate store.

If intermediate certificates aren’t installed on a user’s computer, most browsers use the certificate obtained from the site to reconstruct the whole chain and show the user they are at an SSL site. CardSpace, as it turns out, was not able to get the missing certificates.

Since, this bug could make a legitimate site appear to be fraudulent in CardSpace and because the behavior is intermittent, it might be missed by a web developer adding support for Information Cards to their site.

We asked the IE team and the maintainers of the browser add-on for Firefox to enable CardSpace to retrieve the correct certificate, and they did. The update to IE was included in the October 2007 IE Security Update and the updated Firefox add-on can be downloaded here (thanks Axel!). Implementers of other Identity Selectors should consider whether this issue is present in their code as well. I’ll hand off now to Shan to explain more details about the problem and the fix.

Rob Franco
Lead Program Manager

CardSpace

========

Introduction – How the recipient certificate & its intermediates are retrieved by the browser

When a client navigates to a (https) site in a browser, there is a SSL handshake by the browser with the site. This handshake involves the client receiving the

certificate of the site, and
any intermediate certificates, if any, that are part of the recipient certificate’s issuer chain.

The intermediate certificates (if any) are necessary to build the certificate chain to a trusted root CA for purposes of certificate validation.

Note that CardSpace does an independent validation of the recipient certificate, in addition to the browser.

Why CardSpace certificate validation in .NET 3.0 would fail when intermediate certificates are not present on the client machine

When CardSpace was being invoked by the browser, the intermediate certificates received during the browser SSL handshake were not passed to CardSpace. Only the leaf certificate was passed in. Since the intermediate certificates were not passed in (and CardSpace did not have a mechanism to receive them), the only way for the chain to be built (and validated) successfully by CardSpace was if the intermediates were already present in the local Intermediate certificate store.

Therefore, when intermediate certificates were NOT present on the client machine, CardSpace validation of the recipient certificate would fail even though the site actually chained up to a trusted CA (and showed up fine within the browser).

A possible workaround for this issue

A potential workaround for this problem is to have relying parties certificates utilize the Authority Information Access (AIA) extension (with accesMethod=cAIssuers). This extension, added by CAs in the issued certificates, allows certificate verifiers to retrieve the issuing certificates when intermediate certificates are not present in the verification environment.

However, it may not be judicious to overly depend on the AIA infrastructure as a workaround for this issue. This is because CAs may not choose to include this extension. In addition, it is often unreliable, especially with enterprise CAs. For example, the URL specified in the AIA extension might be invalid or unreachable.

How have we fixed this issue in the .NET Framework 3.0 SP1 version of CardSpace

The CardSpace team has made a fix in the .NET Framework 3.0 SP1 (which ships as part of .NET 3.5) to address this issue. This change enables the Internet Explorer module (or other browser add-ons) to pass the intermediate certificates that were retrieved during the SSL handshake into CardSpace. These intermediate certificates are then used by CardSpace for chain building and validation.

To accomplish this fix, we have added a new version of the recipient-policy struct, namely RECIPIENTPOLICY2 to the updated version of CardSpace API “GetBrowserToken”. The old version of the struct, RECIPIENTPOLICY, which only passes the leaf certificate information, should be considered deprecated.

At the same time, the Internet Explorer (IE) module that communicates with CardSpace to pass certificate information from the browser to CardSpace has been updated to provide the complete certificate chain to CardSpace. This update comes in the October 2007 IE Security Update.

Other Information Card browser add-ons written to invoke CardSpace should also be updated to take advantage of this fix.

Some notes for sites using CardSpace

If you are using CardSpace, you do not have to worry about this issue, assuming your clients will be running the .NET Framework 3.5 AND have the latest IE updates (if they are running IE) or have a version of the Firefox add-on that takes advantage of the fix.

You can check for the right version of CardSpace by checking the user agent string for the following token:

Updated CardSpace (.Net 3.5) = “.NET CLR 3.5.21022”

Details of the fix for browser add-on developers written to invoke CardSpace

(If you are simply a site using CardSpace, then the below section on how to invoke the GetBrowserToken API with the new structures does NOT apply to you)
As mentioned previously, we have added a new version of the recipient-policy struct, namely RECIPIENTPOLICY2 to the updated version of CardSpace API “GetBrowserToken”:

HRESULT

CARDSPACECALL GetBrowserToken(

__in DWORD dwParamType,

__in PVOID pParam,

__out_opt DWORD* pcbToken,

__out_bcount_opt(*pcbToken) PBYTE* ppToken );

This function is currently documented in MSDN: http://msdn2.microsoft.com/en-us/library/aa702769.aspx ) though it has not yet been updated with the .NET 3.5 changes.

To utilize the intermediate certificate fix in .NET 3.5, i.e. to invoke CardSpace passing in the intermediate certificates of the recipient, you would invoke the API in this following way:

dwParamType should be set to value RECIPIENTPOLICYV2 (which is really value 2)
pParam should point to a RECIPIENTPOLICY2 structure (see below)
- For the ENDPOINTADDRESS2,
  - DWORD identityType should be set to 2
  - PVOID identityBytes should be set to a CERTIFICATE_CHAIN_BLOB
    - DATA_BLOB rawCertificates should contain (see struct definition from wincrypt.h below)
      - Count of certificates
      - Bytes of each certificate of the certificate chain retrieved by invoking CertSerializeCertificateStoreElement (which retrieves the bytes of each certificate in the chain in DER encoded form)
      - Note that the recipient certificate is assumed to be the 0^th (zeroth) element of this array, followed by its issuer at index 1 (one) etc., followed by the issuer of the issuer at index 2 (two) and so on.

When invoking CardSpace in the no-SSL case, the identityBytes pointer in the ENDPOINTADDRESS2 structure should be NULL.

typedef struct _RECIPIENTPOLICY2

{

ENDPOINTADDRESS2^recipient;

ENDPOINTADDRESS2 issuer;

LPCWSTR tokenType;

CLAIMLIST requiredClaims;

CLAIMLIST optionalClaims;

LPCWSTR privacyUrl;

UINT privacyVersion;

}RECIPIENTPOLICY2, *PRECIPIENTPOLICY2;

typedef struct _ENDPOINTADDRESS2

{

LPCWSTR serviceUrl;

LPCWSTR policyUrl;

DWORD identityType;

PVOID identityBytes;

}ENDPOINTADDRESS2, *PENDPOINTADDRESS2;

typedef struct _CERTIFICATE_CHAIN_BLOB

{

DWORD certCount;

DATA_BLOB* rawCertificates;

}CERTIFICATE_CHAIN_BLOB, *PCERTIFICATE_CHAIN_BLOB;

typedef struct _CRYPTOAPI_BLOB {

DWORD cbData;

BYTE *pbData;

} DATA_BLOB, *PDATA_BLOB,

NOTE: If your clients do not have the have the updated (.NET 3.5) CardSpace bits, then calling the "GetBrowserToken" API with the new RECIPENTPOLICY2 struct would yield E_INVALIDARG for HRESULT. Therefore if you are a browser add-on developer and do not intend to break .NET 3.0 clients then you would check whether .NET 3.5 is installed before invoking the API with the new RECIPENTPOLICY2 struct.

You can do this by checking for the presence of this key:

[HKEY_LOCAL_MACHINE\Software\ Microsoft\NET Framework Setup\NDP\v3.5]

"Install"=dword:00000001"

If the key does not exist then you would resort to using the original RECIPENTPOLICY struct.

---------------------------------------------------------------------------------------------------------------

We hope this fix helps you keep CardSpace running problem free with your sites!

Sudarshan [Shan] Sundar

Software Development Engineer,

CardSpace Team

What happens when applications don’t get along with CardSpace

CardSpaceBlog — Fri, 29 Feb 2008 02:24:00 GMT

It has come to our attention on the Windows CardSpace team that occasionally there are compatibility issues between CardSpace and other applications. One cause of issue is our use of a private desktop. While the private desktop can not be accessed by programs running as the user; a program can switch to the user desktop so that the user can no longer access the CardSpace UI. The goal of this post is to give you the necessary information to diagnose when an application is conflicting with CardSpace, and provide as much guidance as possible in how to resolve the situation.

What if CardSpace fails when launched?

Let’s say you try and invoke CardSpace by double clicking the “Windows CardSpace” icon in the control panel. If you were to see nothing happen at all, see a flash of the private desktop, or maybe if you see a couple seconds of the private desktop before you are switched back to the user desktop; you may think to yourself, “Whoa! What happened?”. If you try to invoke CardSpace again you might get this message:

Since the message asked politely, you go and look at the “Application” Event Log and check the latest entry for CardSpace. Even if you’re not asked, it’s a good idea to look in the event log if you’re having issues. Let’s suppose you see this:

This message indicates that CardSpace is still open. If the UI had closed during the first failed attempt, then it wouldn’t have been too busy to start the second time. This means that CardSpace is likely still running, and you just can’t see the UI. You should check the task manager for the two entries I have circled below:

These two entries prove that CardSpace did not crash; the CardSpace UI was simply hidden when you were switched away from the private desktop. The error message appears after the second launch attempt due to the fact that the CardSpace service is still running, and can’t start a second instance.

How do I find out which process is causing the problem?

Unfortuntely, up to this point, you probably don’t know which process could be causing the distress. Here comes the hard part. In order to find who may be switching you back to the user desktop it may be necessary to kill every non-essential process, then re-introduce them one at a time to pinpoint the exact culprit. Sites like http://www.processlibrary.com/ provide a quick way to lookup processes to ascertain if they are critical to the operation of your system. It may also be helpful to check the CardSpace MSDN forums for applications that have been noticed to cause issues.

Anti-virus suites, password managers, and other security application are all candidates for application incompatibility. These can be a problem when they injudiciously disallow private desktops resulting in CardSpace being collateral damage.

As of now, once the interfering application is found, the only way to regain CardSpace functionality is to ensure that said application is not running when you use CardSpace. However, if you encounter a problem please let us know on the forum so that we can investigate and follow up where we can.

What now?

I am well aware that application incompatibility is a pain. In an ideal world CardSpace would always work regardless of what applications are installed on your machine. Unfortunately in computing, programs sometimes have competing interests and compatibility issues cannot always be avoided. I can assure you that application compatibility, as it pertains to overall CardSpace usability, will always be considered in future releases, as will our commitment to a high level of security.

You may have noticed I didn’t mention anything about browser plug-ins. If you can start CardSpace from the Control Panel, but cannot invoke it from the browser, it is possible that a plug-in is the culprit. I view this as a completely separate issue, since the root cause is significantly different. I will post a separate entry on plug-ins in the near future.

Thanks,

Brian Houck

SDET – Windows CardSpace

About Relying Party STSs (a.k.a, what is RequireFederatedIdentityProvisioning?)

CardSpaceBlog — Tue, 18 Dec 2007 06:54:14 GMT

A useful, yet sparsely documented feature of Windows CardSpace is its support for resource side Security Token Services (STSs) – STSs that are used by relying parties rather than Identity Providers. Vittorio has done an excellent job helping to provide detail on this subject, and I highly recommend people interested in understanding more about what resource STSs are and why they are useful, read his post. In this post I want to fill out some of the technical details. That said, I'll start with a short introduction to the subject with an example I’ve found particularly helpful.

The canonical CardSpace scenario has a relying party (RP), usually a website, which requires a token from an identity provider (IP). The user selects a card in CardSpace. CardSpace then requests a token from the corresponding identity provider. A token is returned to the CardSpace client, which then sends it to the relying party. Figure 1 shows the RP site, and the IP STS the RP has a relationship with. In the following figures, the line connecting IPs and RPs indicates where explicit relationships exist.

Figure 1

Now, part of the flexibility of CardSpace and the Identity Metasystem, is that it is trivial for an RP to set up new relationships with multiple IPs, as shown in figure 2.

Figure 2

What’s interesting about the case with one RP and multiple IP’s is that the RP site maintains the logic about how to authenticate the various IPs, and potentially has logic to understand the different claims the IPs release (for example one IP could release the claims ‘first name’ and ‘last name’, and another ‘full name’. The RP needs to know how to normalize these into values it understands). Additionally, if the different IPs creates tokens in different formats, the RP needs to know how to understand each of these formats.

This is fine, and a good way for an RP to be able to work with multiple IPs. Now say the RP is part of an organization that needs publish more than one website or web services. Each site needs to duplicate the logic for understanding how to communicate with multiple IPs (show in figure 3)

Figure 3

Clearly for RPs with many sites and many partners, this can become unwieldy. It can be a lot of relationships that need to be maintained in multiple locations. A standard solution to this complexity is for the RP to also run an STS. The relying party’s STS maintains all of the logic around communication with the various IPs, and produces a consistent token format. The other RP sites can then request a token from the RP STS, and only need be able to process this token (figure 4).

Figure 4

RP STSs are not for everyone, but can be a big simplification for complex deployments.

STSs are just specialized web services, so expose policy about how to connect to them, including security requirements. The security requirements may state that issued token is required from another RP STS; this can create a chain of STSs. In the browser scenarios CardSpace automatically follows the RP STS chain, contacting the correct STSs, resolving their policy and continuing to the next STS. In the case of a Windows Communication Foundation (WCF) application, the policy chain can be resolved from a configuration file, but CardSpace itself doesn’t resolve the policy chain (the underlying difference here is a call to CardSpace’s GetBrowserToken() API or GetToken() APIs).

Figure 5

The policy chain can be longer than just a single RP STS, as shown in Figure 5. In this example, the RP Site would specify the requirements of the token it requires from RP STS 1; this would include required claims, STS endpoint URL, and STS metadata exchange policy (MEX) endpoint. Similarly, RP STS 1; would specify the requirements of the token it requires from RP STS 2. RP STS 2 would then specify the requirements for the token it needs. Since the token comes from an IP STS, the only required information is a least one required claim; the details about how to the IP STS can be retrieved from the card the user selects. However, RP STS 2 may also specify an issuer, so only cards from the desired issuer are user selectable.

Of course, the more STSs in the chain, the more processing time is required to request all of the tokens. This delay will be noticed as CardSpace starts (chasing the policy chain) and when it closes (retrieving the tokens). During these delays, the user sees the CardSpace progress page (figure 6).

Figure 6

To get CardSpace to follow an STS chain, it needs to be given the STS endpoint and MEX policy endpoint of the RP STS, as well as the claims that are being requested from the RP STS. This can be done from a web site by using the x-informationCard object tag. The issuer param is used to specify the STS endpoint, issuerPolicy specifies the MEX policy endpoint.

CardSpace will retrieve the policy from the issuerPolicy URL. Since a MEX policy can define policy for multiple STSs, the issuer URL must match one. The policy for the RP STS is then used to decide what to do next. If it is an IssuedToken request that can be satisfied by a self issued or managed card, CardSpace shows the user her cards, and the usual user interaction begins. One interesting point to note; the policy from the RP STS, not the RP site, is used for card selection. This makes sense, because the token returned by the IP STS must satisfy the RP STS requirements and the token from the RP STS satisfies the requirements of the RP website.

The steps in a CardSpace interaction with an RP website, RP STS and IP STS, are listed below, and shown in figure 7.

1) The user goes to the RP website

2) Token requirements are returned via the x-informationCard object tag

3) CardSpace queries for policy from the RP STS

4) Policy is returned from the RP STS

5) The user selects a card that matches the RP STS policy

6) CardSpace makes a request for a token from the IP STS (RST)

7) The token is returned from the IP STS to CardSpace (RSTR)

8) Using the token from the IP STS, makes a request for a token from the RP STS (RST)

9) A token is returned to CardSpace (RSTR)

10) CardSpace returns the token to the site

Figure 7

For an example that you can try, check out the age sts at Identity Lab. The page requests the claim ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/age’ (this is just a made up claim URI and not defined anywhere) from an RP STS; that is, the age STS. The age STS requests a self-issued card with the claim ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/DateOfBirth’. When a user goes to the page, she needs to submit a self-issued card, which contains a ‘Date of Birth’ claim. This is sent to the age STS, which calculates age and creates a new token, which is returned to the web site. The web site then shows the claim values it has received, in this case, the age. In this scenario, the age STS is playing the role of a claim transformer, as described in the Identity Metasystem.

As previously stated, the RP STS’s policy is used for card matching. Similarly, if the RP STS requests a PPID, it is the RP STS certificate that is used for calculating the PPID, not the certificate of the RP site. This is so a single RP STS can service multiple sites, but always gets the same PPID for a given user from CardSpace.

The certificate information CardSpace shows the user is that of the RP site, even though the policy is used from the RP STS. This may seem somewhat contradictory, however since the RP site is truly the site the user is visiting; the user needs to make a trust decision about it. If the site chooses to use a RP STS, this is more an implementation detail, and by choosing to trust the RP site, the user indirectly trusts the services that site chooses to use.

In addition to the RP site cert getting shown in CardSpace, it is also used to track card usage history. So if a card is used at two different RP sites that rely on the same RP STS, two separate entries will be created in the card history.

The astute reader may notice I’ve only handled cases where the RP site and RP STS have a certificate, and may wonder what would happen if the RP web site uses HTTP, which now works with CardSpace. The answer is the RP site and RP STS must both have certificates. The support of HTTP only sites was made to help smaller sites that may not have much in the way of security requirements, but still want to use CardSpace. However, the RP STS support is targeted at sites and organizations which have more complex scenarios, for whom the procuring a certificate and using HTTPS for additional security is likely to already be a security requirement.

For the actual STS endpoints HTTPS (transport) is not required, however the binding the STS uses must have a certificate. This could be provided by transport or message security. The examples in this post use message security for the STS endpoints, which is why the STS URLs start with HTTP, yet they still have certificates associated with them.

Ok, now for a quick quiz.

Say there is an RP website that contains the below object tag.

And the policy at the MEX endpoint, ‘https://ipsts.federatedidentity.net/sts.svc/mex’, declares a requirement for a token with the issuer ‘http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self’ and claim ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname’ and ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname’. That is, the STS is requesting a token from a self-issued card that contains a first and last name.

How is the resulting flow best described?

a) The website is requesting a token from an RP STS. The RP STS is requesting a token from a self-issued card. So the user will see CardSpace UI open and will get to pick which self-issued card to use. The self-issued token is then sent to the RP STS, which generates a token that is sent to the RP web site.

b) The website is requesting a token from an IP STS. CardSpace opens and the user selects the managed card whose issuer is ‘http://ipsts.federatedidentity.net/sts.svc’. Authentication to the IP STS is done with a self-issued card, so on selection of the managed card CardSpace automatically sends the token generated by the correct self-issued card to the IP STS. The token from the IP STS is then sent to the RP site.

c) Not enough information.

This really was kind of a trick question. The right answer is c) not enough information. It may be tempting to say a) since a MEX endpoint is defined in the object tag. However, IP STSs have MEX endpoints as well, it just isn’t necessary to include them in the object tag for IP STSs, since the MEX endpoint is also defined in the managed card. So the presence of a MEX endpoint in the object tag is only required when using an RP STS, but does not guarantee that an RP STS is being referred to. If you think about it, it would seem strange for the RP site to be the one dictating if the next STS in the chain is an IP STS or RP STS; that decision should authoritatively be made and expressed by the STS itself. Still, it is probably good practice not to specify the MEX endpoint (issuerPolicy) for an IP STS, since the MEX call will need to be made again anyway when the managed card is used, and just calling once will be faster. Also, not including the MEX endpoint makes it so the RP site won’t be affected if the MEX URL changes for any reason.

That leaves the obvious question. If there wasn’t enough information, what other information is needed? The answer lies in the MEX policy of the STS. If it is an IP STS, it will have the element <ic:RequireFederatedIdentityProvisioning xmlns:ic=”http://schemas.xmlsoap.org/ws/2005/05/identity” /> in its policy. The following description of RequireFederatiedIdentityProvisioning appears in Identity Selector Interoperability Profile V1.0

This element indicates a requirement that one or more information cards, representing identities that can be federated, must be pre-provisioned before token requests can be made to the identity provider.

In other words, the element is placed at federation boundaries. When crossing a trust boundary it makes sense that a user interaction may occur, and cards are great way for the user to be involved. Back in figure 4, the box drawn with the dashed line represents a trust boundary around the RP. All sites and STSs in the boundary often don’t require user interaction when communicating with each other, since all tokens passed around are within an organization. Also since it is between parties in the same organization, there should not be any privacy concerns. However, as soon as the boundary is hit, as in the case of federation, it makes sense for the user to be prompted. Note, in most cases this boundary will be between organizations, but it could even be in an organization if the information being passed is not already freely shared between the group running the RP STS and RP site.

This element was described in a fairly straightforward scenario, but it is actually required to resolve ambiguities in many cases, such as in the case that a web service is accessed by an application using the WCF stack, the stack needs to have a way to know if CardSpace should be invoked. The credential required to authenticate to the final STS in a chain can be collected in other ways than just CardSpace, such as when the credentials of the currently logged in user are used, or the user is prompted directly for username and password through some custom application. If the RequireFederatedIdentityProvisioning element is in the last policy in a policy chain (or one from the last), CardSpace will be called.

WCF developers may be wondering how to set RequireFederatedIdentityProvisioning in policy, from config. It is done by using the <useManagedPresentation> binding element.

In Summary

Hopefully this provides a good reference for people interested in understanding RP STS.

I’ve tried to give a quick explanation of what a RP STS is, as well as a case in which it may be used. I think some of the key take-away points are:

1) CardSpace also works with RP STSs, which consume the tokens represented by cards.

2) There can be multiple RP STSs in a chain.

3) CardSpace must be given the MEX endpoint URL of an RP STS, either from the WCF app config or from the issuerPolicy element in the x-informationCard object tag for browser applications.

4) Each RP STS needs a certificate, and the web site making the initial request must use HTTPS.

5) <RequireFederatedIdentityProvisioning> is the hint to CardSpace that an STS is an IP STS – not an RP STS.

Please let me know if you have any questions, or can think of any CardSpace topics that could use some more documentation.

Thanks,

Caleb

CardSpace on FAT File Systems

CardSpaceBlog — Tue, 11 Dec 2007 05:07:10 GMT

The version of Windows CardSpace that shipped in .NET Framework 3.0 will not run when installed on a FAT file system. We’ve received a surprising amount of feedback (some of the earliest from Pamela Dingle) that customers are still using FAT file systems and this is causing problems. This was done because FAT doesn’t provide ACLs and therefore the files CardSpace uses for storing cards can be deleted or corrupted by malicious code running as the user. Since the store files are still double encrypted by both the user’s and the system’s keys, even on a FAT drive, user code cannot access the contents of the file and read the secret card information. Given the feedback we received, and that the cards are still protected against theft, we decided to make the changes and enable CardSpace (shipped with .NET Framework 3.5) on FAT File Systems. This change doesn’t have any side effect on the rest of the product so running CardSpace on partitions formatted with FAT or NTFS produces the same results.

This is a change intended to meet some customers’ demands but we still recommend the use of NTFS because it’s a more secure environment not only for CardSpace but also for all other files in the computer.

Rafael
Windows CardSpace Team

CardSpace support for Oasis WS-SX standards

CardSpaceBlog — Thu, 22 Nov 2007 06:40:00 GMT

The OASIS Web Services Secure Exchange (WS-SX) technical committee has published specifications for WS-Security extensions and policies to enable the trusted exchange of SOAP messages. Their effort resulted in the WS-SX specifications that include WS-Trust, WS-Security policy and WS-Secure conversation. This standardization of WS-Trust is good news. Gartner says that:

OASIS's ratification of two key standards means that Web services security has finally reached a level of maturity acceptable to many enterprises. This is a positive development for vendors and customers alike.

The ratification happened in March 2007 and support for these standards was one of the main changes included in the .NET Framework 3.5 release of CardSpace.

Overview of new WS-Trust specification

The OASIS WS-Trust is very similar to the one people have been using. The main differences are:

1. Returning the security token: a RequestSecurityTokenCollection element is used to return a security token in the final response.

2. SecondaryParameters: When a requestor inserts parameters into an RST request that come from a third party, for example a relying party policy, there is a potential for an attack. In the contributed request, both requestor RST parameters and third party RST parameters are mixed together as direct children of the wst:RequestSecurityToken element. This prevents an STS from differentiating between the RST parameters based on their source. Therefore, the STS trusts both kinds of RST parameters in the same way. This can open a potential attack vector because the third party is given control over the content of the RST message that the requestor sends to the STS. For this purpose, a new element wst:RequestSecurityToken/wst:SecondaryParameters was introduced, that acts as a bag for RST parameters introduced by a third party. This allows an STS to mitigate the attack by differentiating parameters originated by the requestor and parameters not originated by the requestor. Note that same element can occur as direct child of <RequestSecurityToken> as well as child of SecondaryParameters.

3. Bearer tokens: This trust version supports bearer tokens.

4. Namespace changes: A new namespace http://docs.oasis-open.org/ws-sx/ws-trust/200512 was introduced. This affects the URI for KeyType, RequestType and SOAP Action on the STS endpoint. For e.g., the symmetric key type is http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey in place of http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey.

5. Batch requests possible: In scenarios where multiple RSTs need to be sent, it is now possible to send them all at once using a RequestSecurityTokenCollection. This helps avoid multiple network round-trips. (Not a CardSpace scenario)

How does this all affect CardSpace?

First I would like to clarify that the CardSpace changes for the new WS-Trust version implement an additional feature. CardSpace will continue to support the previous WS-Trust specification (http://specs.xmlsoap.org/ws/2005/02/trust/ws-trust.pdf) having the namespace http://schemas.xmlsoap.org/ws/2005/02/trust.

If you have developed an STS or rich applications using the previous trust version, those will continue to work.

Which scenarios can leverage the new trust specification?

1. Managed card scenarios: An Identity Provider can choose to use the new trust version

2. A web service: Rich web services based on WS-* protocols can choose to use the new trust version. E.g., a Calculator web service built using WCF that uses CardSpace to secure its service endpoint.

3. Resource-STS: A resource STS can choose to use the new trust version. The Resource STS can serve either a website or a web service (as in previous point).

Note that the scenario involving a website asking for a self-issued card cannot leverage the new trust version.

CardSpace behavior when the new trust version is involved

1. Identity Provider: The Identity provider issues managed cards and generates token on demand. The card issuance is not affected at all. For token generation, following is the new behavior:

a. Policy retrieval: CardSpace determines the trust version used by the IP STS based on the policy. The policy needs to be expressed using the WS-SX version of security policy and use the Trust13 assertion to specify its WS-Trust capabilities. When using WCF for building the STS, use bindings such as WS2007FederationHttpBinding or CustomBinding with a security version like WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12 for the appropriate policy to be generated. Sample policy snippet looks like:

<wsp:Policy wsu:Id="policy">

    <wsp:ExactlyOne>

        <wsp:All>

            <ic:RequireFederatedIdentityProvisioning xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity"></ic:RequireFederatedIdentityProvisioning>

            <sp:SymmetricBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

                ...

            </sp:SymmetricBinding>

            <sp:SignedEncryptedSupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

                ...

            </sp:SignedEncryptedSupportingTokens>

            <sp:Wss11 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

                ...

            </sp:Wss11>

            <sp:Trust13 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

                <wsp:Policy>

                    <sp:MustSupportIssuedTokens></sp:MustSupportIssuedTokens>

                    <sp:RequireServerEntropy></sp:RequireServerEntropy>

                </wsp:Policy>

            </sp:Trust13>

            <wsaw:UsingAddressing></wsaw:UsingAddressing>

        </wsp:All>

    </wsp:ExactlyOne>

</wsp:Policy>

b. STS Contract: Due to the change in namespace, the contract will have to be modified accordingly. For e.g., when using WCF, the operation will be as below:

[OperationContract(

    Name = "Issue",

     Action = "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue",

    ReplyAction = "http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal" )]

Message Issue(Message request);

c. RST parsing:

i. KeyType: Due to the change in namespace, the parsing of the KeyType will have to be modified to support the new URIs for symmetric, public, and bearer (no-proof) keys

ii. RequestType: Due to the change in namespace, the parsing of the RequestType in RST will have to be modified.

iii. Claims: The claims are always sent in the top-level RST body.

iv. SecondaryParameters: CardSpace will send the parameters it receives from resource (or Relying Party) as an xml blob within the SecondaryParameters. The secondary parameters are skipped in the following cases:

· The user chooses not to send optional claims. In this scenario, secondary parameters are omitted to hide this user decision

· The situation is such that no wsp:AppliesTo is being sent in the RST. In this scenario, secondary parameters are omitted so that IP does not get any identifying information about resource/RP.

Sample RST looks like:

<wst:RequestSecurityToken Context="ProcessRequestSecurityToken" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">

<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>

<wsid:InformationCardReference xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/identity">

</wsid:InformationCardReference>

<wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity">

...

</wst:Claims>

<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>

<wst:SecondaryParameters>

<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>

<wst:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>

<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>

<wst:KeyWrapAlgorithm>http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</wst:KeyWrapAlgorithm>

...

</wst:SecondaryParameters>

</wst:RequestSecurityToken>

d. RSTR construction: The issue response has to be wst:RequestSecurityTokenResponseCollection (RSTRC). Within this RSTRC, a single RSTR is expected. In case the STS emits a RequestType in the RSTR, the URI to be sent needs to be changed as per the new namespace. A sample RSTR snippet looks like:

<wst:RequestSecurityTokenResponseCollection xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">

    <wst:RequestSecurityTokenResponse>

        <wst:TokenType>urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>

        <wst:RequestedSecurityToken> ... </wst:RequestedSecurityToken>

        ...

    </wst:RequestSecurityTokenResponse>

</wst:RequestSecurityTokenResponseCollection>

2. Resource STS: A web service resource or a website can delegate the task of authentication/authorization to a resource STS. In such a scenario, the Resource STS will have to set up an endpoint to process the RST/RSTR similar to an IP STS. All the points mentioned for Identity providers are applicable in this case. The changes are in the RST parsing.

It is no longer assured that the typical properties like claims and keytype will always be a direct child of the top level wst:RequestSecurityToken element. The RST parsing code will have to look into wst:RequestSecurityToken/wst:SecondaryParameters in case it finds information missing from the top-level elements.

3. Web service: A web service can act as a resource in rich client scenarios. When such a web service uses CardSpace for authentication, it can potentially use the WS-SX trust version. The resource will have to express its policy using WS-SX version of security policy and use the Trust13 assertion to specify its WS-Trust capabilities. In case of WCF resource, you can use Ws2007HttpBinding, Ws2007FederationBinding or a CustomBinding with an appropriate security version like WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12 to accomplish this.

4. Token generated by self issued card: CardSpace in .NET Framework 3.5 understands the WS-SX standards. So when a self issued card is requested using a WS-SX based policy, the token generated will process and comply with the parameters like KeyType, KeySize, etc. expressed in the policy. A sample scenario where this is possible is a Web service or a Resource STS asking for a self-issued card.

5. Bearer tokens: Consider scenario of website asking for a managed card. Since browser is a passive client, it cannot do proof of possession. Hence, CardSpace v3.0 used the concept of KeyType=NoProofKey in scenarios like this. The WS-SX version of WS-Trust introduced concept of requesting bearer tokens to address such scenarios. A new KeyType value http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer is added. CardSpace in .NET Framework 3.5 will use this new URI value for the KeyType element in the RST when the IP STS is using the new trust version. Note that rich client support for bearer tokens is not implemented in CardSpace.

Mixed trust versions

Things can get confusing when different legs of the scenario use different trust versions. For example, consider the following scenario:

A web service or a website is requesting a token from Resource STS. This Resource STS is asking for a managed card. The IP STS uses WS-SX version of WS-Trust (Trust13). And the Resource STS uses older WS-Trust (Trust10). The RST that is received by the IP STS will have the policy of the Resource STS in its SecondaryParameters. But since these parameters will be in Trust10, the contents of the SecondaryParameters element will also be in Trust10.

<wst13:RequestSecurityToken Context="ProcessRequestSecurityToken" xmlns:wst13="http://docs.oasis-open.org/ws-sx/ws-trust/200512">

...

<wst13:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst13:KeyType>

<wst13:SecondaryParameters>

<wst10:KeyType xmlns:wst10="http://schemas.xmlsoap.org/ws/2005/02/trust">http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</wst10:KeyType>

...

</wst13:SecondaryParameters>

</wst13:RequestSecurityToken>

This can complicate the parsing of RST. The Identity Provider will have to decide on an approach for such scenarios like not supporting it, or ignoring SecondaryParameters or parsing of parameters in Trust10 namespace.

Thanks!

Rakesh Bilaney

SDET, Windows CardSpace

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

User Experience Changes to Site Information Page

CardSpaceBlog — Tue, 02 Oct 2007 08:22:00 GMT

Based on feedback from usability studies and CardSpace users we made a number of changes to CardSpace in the .NET Framework 3.5 release. Some of these changes were designed to make CardSpace easier to use. The first of these changes we'll describe are to the page shown the first time you visit a site. This page provides you with information about that site to help inform your choice to either "Yes, choose a card to send" or "No, return to the site".

We've changed the Site Information Page to make it cleaner and to bring forward the most pertinent details to the user. We’ve also added several visual cues to alert the user to the level of security a particular site has.

The Site Information Page falls into 3 modes:

· Extended Validation (EV) SSL Certificate Mode

· Regular SSL Certificate Mode

· No Certificate Mode

Extended Validation SSL Certificate Mode:

.NET Framework 3.0 Windows CardSpace Site Information Page (OLD):

.NET Framework 3.5 Windows CardSpace Site Information Page (NEW):

Green Background Color

Following the green address bar that web browsers have implemented for EV certificates, it helps create a consistent experience by following the same coloring scheme to display recipient information in.

Lock Symbol

We added the common lock symbol used to signify SSL protection.

Regular SSL Certificate Mode:

.NET Framework 3.0 Windows CardSpace Site Information Page (OLD):

.NET Framework 3.5 Windows CardSpace Site Information Page (NEW):

Major Internet Business Warning

We have received a lot of feedback pertaining to the warning we show at the top of the page for sites that are protected by an SSL certificate but not an EV certificate, specifically that the wording was too strong. So we’ve downgraded the warning to a notice, while still trying to be true to the intent of the notice, to let the user know that the site could take advantage of stronger forms of verification. We removed the lines which state Organization/Location not verified and just don’t display that information to the user.

Lock Symbol

We added the common lock symbol used to signify SSL protection.

No Certificate Mode:

Since we didn’t support non-SSL sites in .NET Framework 3.0, there isn’t an old screenshot we can use to compare and contrast.

.NET Framework 3.5 Windows CardSpace Site Information Page (NEW):

No Protection/Encryption Warning

We wanted this page to really pop out to warn the user that there is no protection with this particular recipient and any data you send to this recipient will not be encrypted and will be sent in the clear.

//Toland Hon