“Geneva” Team Blog : managed card

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

Information Card Issuance: a small step for "Geneva" Server, a big leap for Federated Identity

CardSpaceBlog — Fri, 29 May 2009 05:26:00 GMT

Imagine this: you have been following this blog and have decided to try “Geneva” Beta 2. You have gone to the connect site and downloaded the "Geneva" platform components, installed them, configured the server, used the framework to write a claims-aware uber cool application, and set up trust between your server and the application. Now your users can log in and use your application and you can manage access easily. But that uses only two out of the three "Geneva" products. What does it mean to incorporate CardSpace "Geneva" into this scenario? From the server perspective, it means configuring information card issuance.

Intro

The "Geneva" Server in this scenario is configured to use the active directory that contains all your users. We call this role an Identity Provider STS because it authenticates users and produces tokens about their identities. One of the powerful features that “Geneva” Server gives an STS is the ability to issue cards that CardSpace "Geneva" stores and allows you to use to authenticate. For more information on cards see: http://blogs.msdn.com/card/archive/2008/05/20/backing-a-managed-card-with-alternate-credentials.aspx

Each part of our scenario needs to be properly configured:

· Your users need to have CardSpace “Geneva” installed (or compatible Identity Selector)

· The Server needs to issue cards.

· The application needs to support card selector log in

"Geneva" Server Card Issuance

Configuring a card is simple: the initial configuration wizard sets all required parameters. You can update any and all of them at any time. List of the parameters you can set:

· Card name

· Card image (typically your organization's logo)

· Privacy Notice (optional)

· Authentication type (more in the next paragraph)

· Certificate to sign the card (this is located in the certificate settings)

Choosing an authentication type depends on your deployment, and the strength of authentication you wish to enforce. “Geneva” Server Beta 2 supports three types of authentication:

· Windows – by selecting this type, CardSpace performs Windows Integrated Authentication, which only works when the user is connecting from the internal network.

· Certificate – by selecting this type, CardSpace authenticates with a user certificate located on the user’s machine. This type works well for smart cards, and is especially useful for authenticating users outside of the corporate network in a highly secure way.

· Username and password – by selecting this type, CardSpace prompts the user for their domain user name and password. This type also works for authentication outside the corporate network.

The order of the authentication types will always be first Windows if present, next Certificate if present and last Username Password if present. The implication of this is that if you can turn on two authentication types, for example Windows and Certificate. Then inside a corporate network, users would automatically get authenticated with Windows Integrated Authentication. Outside a corporate network where Integrated Authentication is not available, authentication falls down on the next authentication type and users will get authenticated by their user certificate.

The initial configuration wizard does one more thing for you. It deploys a card issuance website from where users can download your spiffy new card. Note that by default access to the site is windows authentication based. Once the website is deployed you can customize it with your organization's name, logo, contact information, etc.

Tips

A subset of the settings that are part of the card file your users will download is derived directly from the STS settings. However to give the administrator more control over the process, changes to the STS that affect the card will not be applied to the card until the administrator chooses to do so and clicks the “Update Information Card” action.

The “Geneva” Server Beta 2 gives you a powerful new way to configure and maintain your configuration: PowerShell. I’d like to briefly note that there is a resource dedicated to configuring card issuance: GSInformationCard. There are five different cmdlets/verbs associated with this resource:

· Get-GSInformationCard,

· Set-GSInformationCard,

· Enable-GSInformationCard,

· Disable-GSInformationCard

· Update-GSInformationCard.

The GSInformationCard resource covers all UI capability and some additional parameters not visible in the UI, like explicitly adding claims and in depth management of certificate backed cards amongst others. Look to future posts for more details.

Conclusion

As you can see, “Geneva” Server provides quick access to the world of information cards:

· Simple, secure provisioning of cards to users

· Simple administration of the card

· Flexibility to provide/ensure specific authentication types

· Customizable site to provide users with familiar corporate site experience

A great reference for setting up information card issuance you can find here: http://technet.microsoft.com/en-us/library/dd807042(WS.10).aspx. And in the next post you are going to learn about a powerful feature build on top of card provisioning: silent card provisioning.

Veneta Tashev

Software Development Engineer in Test

“Geneva” Server Team

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