The Beta 2 version of “Geneva” has many features that improve the deployment of Geneva platform for our enterprise customers, like the Group Policy-driven provisioning of Information Cards or the administrative policy of card usage that we talked about in our previous blog posts.
Another such feature is the enhanced support for X.509 certificate credentials in Information Cards.
Using Information Cards backed by an X509 certificate provides the added benefit of increased security, and with “Geneva” Server Beta 2 it becomes very easy to provision such a card. Pretty much all that you need to do is to check the “Certificate” checkbox in the Information Card Properties dialog in Geneva Server (right-click on Information Card tab in the navigation pane, and select Properties from the context menu).
For more information about how to find this setting using the Geneva Server Management snap-in, see http://technet.microsoft.com/en-us/library/dd807081(WS.10).aspx.
Once cards are provisioned, the rest of the pieces are handled by the existing Public Key Infrastructure (PKI) mechanisms that distribute certificates to users. If you then configure automatic card provisioning, CardSpace “Geneva” Beta 2 silently download the card onto users' machines. Alternatively, users can browse to the Geneva Server Card Provisioning web page and install the card with a couple of clicks.
This is a great improvement from what was previously possible and here’s why. Until now, users had to first select the certificate manually and only then could they download a certificated-backed card from the Card Provisioning web page. Furthermore, these cards could not be automatically provisioned, and had to be re-installed when the certificate was renewed.
How it all works
The difference in the experience stems from how the certificate is referenced in the Information Card. Until now, a certificate could only be referenced by its thumbprint in the card data. This limitation created two problems.
First, users had to manually select the desired certificate, or otherwise supply the thumbprint to the Card Provisioning service before downloading a card. This fact prevented the automatic provisioning of a certificate-backed card.
Second, when a certificate is renewed, its thumbprint changes, and this causes the card to become invalid.
To address these problems, we have extended the Information Card schema by adding two more types of references: PrincipalName reference and SubjectAndIssuer reference. These references can be obtained by querying the Active Directory and need not be supplied by the user, unlike thumbprint references.
PrincipalName reference is obtained by querying AD for the userPrincipalName attribute of AD User Object. This should be equal to the value in the Principal Name field of the X.509 certificate.
Here’s an example of a PrincipalName reference in a card:
<X509Principal>
<PrincipalName>alans@contoso.com</PrincipalName>
</X509Principal>
SubjectAndIssuer reference is obtained by querying AD and parsing the altSecurityIdentities attribute of the AD User Object. This reference holds the Subject Name and Issuer Name values from the certificate. Here’s an example of a SubjectAndIssuer reference in a card:
<X509SubjectAndIssuer>
<X509Subject>CN=Alan Smith,DC=contoso,DC=com</X509Subject>
<X509Issuer>CN=Contoso-CA,DC=contoso,DC=com</X509Issuer>
</X509SubjectAndIssuer>
Using these references CardSpace “Geneva” finds the correct certificate from the user's certificate store during authentication.
Configuring Geneva Server
Referencing certificate using UserPrincipalName
Geneva Server uses the PrincipalName reference by default. The method of mapping the Principal Name field of the certificate to a User Principal Name (UPN) attribute of the user’s account (also known as implicit mapping) is widely used and should work in most PKI deployments.
Referencing explicitly mapped certificates
In certain PKI deployments, however, certificates are mapped explicitly to users’ accounts in AD. In these cases UPN is not the right reference to use. The Geneva Server Administrator can change the default setting and use a SubjectAndIssuer reference instead. This can be done with the following PowerShell commands:
|
PS C:\> Add-PSSnapin Microsoft.IdentityServer.PowerShell
PS C:\> Get-GSInformationCard | Set-GSInformationCard -UseExplicitlyMappedCertRef $true |
The first command adds the Geneva Server PowerShell snap-in. The Second one sets the value of UseExplicitlyMappedCertRef attribute to true, meaning that the certificate reference will be produced based on the explicitly mapped certificate value rather than on the UPN attribute.
Matching certificates based on the Extended Key Usage (EKU) field
In some PKI deployments users may have certificates that are intended for various uses, such as an encryption certificate or a certificate that lives on a smartcard. Each such usage policy is listed in the Extended Key Usage (EKU) section of the X.509 certificate and it has an associated ID, called an Object Identifier (OID). For example, “Client Authentication” has an OID of 1.3.6.1.5.5.7.3.2.
Information Cards generated by Geneva Server by default reference certificates with “Client Authentication” EKU OID in combination with the primary reference of PrincipalName or SubjectAndIssuer.
Administrators may want to change the default behavior to suit their particular needs. For example, they may want their users to use a smartcard when authenticating to the STS. To change the default setting and, for example, add the “Smart Card Logon” OID (1.3.6.1.4.1.311.20.2.2) the following PowerShell command can be used:
|
PS C:\> Get-GSInformationCard | Set-GSInformationCard -RequiredEkuOids "1.3.6.1.5.5.7.3.2", "1.3.6.1.4.1.311.20.2.2" |
This command sets the value of RequiredEkuOids to {“1.3.6.1.5.5.7.3.2", "1.3.6.1.4.1.311.20.2.2”}, which is an array of 2 strings. With the current settings, CardSpace “Geneva” will only select a certificate that has both the “Client Authentication” and “Smart Card Logon” EKU policies.
Dan Guberman
Program Manager
“Geneva” team
