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

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”

Comments

• Anonymous
  June 15, 2009
  Silent Information Card Provisioning One obstacle that administrators looking to deploy information cards