“Geneva” Team Blog

Improved support for X.509 credential in Information Cards

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:

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:

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

Silent Information Card Provisioning

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

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”

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

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

“Geneva” Server Team

Identity Developer Training Kit – Featuring Geneva Framework Beta-2 and other identity products

With all the new “Geneva” Beta 2 products introduced at TechEd you may wonder how long it is going to take you to learn these new technologies. Well, the DPE team and the Geneva team thought about this and are happy to offer a developer focused training package, introduced as part of Geneva Framework Beta-2, named as “Identity Developer Training Kit (May 2009)”. This is a training kit for ASP.NET and WCF Developers intended to help them learn about how to build an end-to-end identity related scenario using Microsoft’s latest identity and access control developer products.

This kit contains a set of hands-on-labs, documents, and reference materials and covers the following products:

·         Microsoft “Geneva” Framework Beta 2

·         Microsoft “Geneva” Server Beta 2

·         .Net Access Control Service (March CTP)

·         Microsoft Federation Gateway

You can download the identity developer training kit (May 2009) here.

Also, here are links from Vitorrio's blog of the annoucement of availability of these kits, as well as more details.

If you are an ASP.NET developer be sure to check out the “WebSitesAndIdentity” lab which covers various exercises such as how to claims enable an existing ASP.NET application, federating with Geneva Server and LiveID STS from an ASP.NET application, and how to make use of Identity Delegation in an ASP.NET application. If you are a WCF developer be sure to check out the “WebServicesAndIdentity” lab which provides exercises for making your WCF service claims-enable and connecting it with an STS and then adding identity delegation capability to it. There are aspects of Access Control Service covered in this kit as well!

In addition, if you are looking for a site that is full of identity related videos, stop-by at “The Id Element” site – the one-stop shop for all things identity on Channel9. You can watch videos that cover the “what’s new in Beta 2” and deep dive of specific topics on identity products. These are videos covering interviews with the product team members who build these products and would wow you!

Enjoy coding!

Step-By-Step Guides, Virtual Machines and "Geneva" Whitepapers

“Geneva” Step-by-Step Guides and Virtual Machines

The Step-by-Step guides and virtual machines that were used at the Tech Ed "Geneva" hands on labs and sessions are now available for download.  You should find these helpful if you were unable to get to TechEd, missed the Geneva hands on lab sessions, or just want to be able to go through the material at your own pace. They are a great way to get your hands on and play with the Geneva technology.

You can download these materals from here.

“Geneva” Interop Whitepapers

Also available are our "Geneva" interop whitepapers. These cover:

• "Geneva" and Sun OpenSSO
  
  Interoperability between applications in heterogeneous technology environments is essential to successful collaboration between organizations today. Sun and Microsoft are taking interoperability to a new level by utilizing the SAML federation standard in both the Sun OpenSSO Enterprise federation solution and the forthcoming Microsoft “Geneva” Server federation solution.
  
  By standardizing on SAML for federation, Sun and Microsoft enable organizations to deliver collaborative services with ease.
• "Geneva" and Novell Access Manager
  
  Despite remarkable gains in IT capabilities and collaboration, organizations continue to struggle with administrative complexity, workforce productivity, and data security. Many organizations support a large number of users—including employees, customers, partners, and suppliers—who seek access to a wide variety of applications and services. This can be particularly challenging in mixed-technology and multiple-domain environments where users are spread across technical and business boundaries.
  
  Microsoft and Novell have come together to solve these challenges and boost cross-organizational collaboration. The two companies are building the interoperability bridges that enable customers to reduce complexity, enhance security, and decrease costs. This paper explains the need for standards-based identity federation, and the current and forthcoming solutions that improve the interoperability of mixed-technology directory environments.

What’s New in Geneva Beta 2

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

“Geneva” at RSA2009 and TechEd

For the last several months, the Geneva team (CardSpace, Framework, and Server) have all been heads down, working on getting our Beta 2 out the door. And now, we are finally in the home stretch!

Geneva featured in RSA2009 keynote

Geneva will be at TechEd

TechEd is coming up very soon. May 11-15, 2009. And the Geneva team will be there! There will be many sessions talking about Geneva, including two Hands-On-Labs. For a list of sessions, click here. (key word: Geneva) Additionally, we will, of course, have a booth at the expo where you can come by and meet us, or ask us questions.

Please stop by and give us your feedback!

Geneva TAP (Technology Adoption Program) Status

We have been overwhelmed by the amount of enthusiasm and the number of the very compelling applications to join our TAP. It was a very difficult process to try to choose the right set of varied scenarios and customers to support. We wanted to try to cover as diverse a set of different usage scenarios and customers as our team could support. But now, I am happy to say that our TAP program is underway. In the coming months, the things we learn from how these customers are deploying and using Geneva should find their way into a set of best practices and templates that everyone will benefit from. Expect to hear more about this in coming months as these take shape.

The CardSpace "Geneva" Control Panel Applet

Hello! My name is Robert Zhu and I am a developer on the CardSpace team. Today, I'd like to invite you on a brief tour of the CardSpace Control Panel Applet. The Control Panel Applet deals with the management of your Information Cards. From this component, you will be able to view, modify, and delete any Information Card in your possession. In addition to managing Cards, the Control Panel Applet also provides the ability to reset card history (card history keeps track of the Relying Parties at which specific Information Cards were used and what information was released).

To try it out, follow the steps below:

1- Install the CardSpace “Geneva” Beta

2- Install any card from the test site

3- Launch the CardSpace Control Panel Applet from the Control panel:

     Control Panel -> User Accounts -> Windows CardSpace “Geneva”

Once you double-click on the Windows CardSpace “Geneva” icon, you should see the Management Interface (below):

The main page shows a complete collection of your Information Cards. To select an Information Card, click on it, and a blue highlight box should appear around your selection. Hold down CTRL while clicking to select multiple cards, or use CTRL+A to select all cards. Once you have made your selection, you can delete the specified cards by clicking the “Delete Card” link on the right. If you have just added a new Information Card to your collection, pressing ‘F5’ will refresh the list of cards.

As mentioned before, the Control Panel Applet provides the ability to reset all card history. To do this, click the “Delete all card history” link on the top left of the Management Interface. As mentioned in Oren’s post regarding automatic submission of credentials (http://blogs.msdn.com/card/archive/2008/11/18/the-cardspace-geneva-selection-experience.aspx#9128068), CardSpace displays a matching card that has been previously used at the site on subsequent visits. This decision is made by inspecting the card history; thus, deleting the card history has the consequence of resetting all your previous Card/RP associations. Think of it like clearing your browser’s page history.

In the future, we will be adding more features to the Management UI. Thanks for reading and your feedback is extremely valuable!

Robert Zhu,

Software Design Engineer

CardSpace “Geneva”

Using the CardTile with “Geneva” Framework

In an earlier posts, Colin described how to handcraft a web page to implement the new CardTile feature of CardSpace “Geneva” and Oren points out a way to require user interaction during authentication. This post will now explain how the “Geneva” Framework makes implementing these features quick and easy.

The InformationCard Control

As mentioned in the introduction to the “Geneva” Framework, one of the biggest goals of the framework is to give developers the ability to build secure Relying Party (RP) websites with ease and still give them flexibility in website design. One way that we do this is with the InformationCard control. This new control allows developers to leverage the security of InformationCards on their web site with minimal effort while being able to customize its behavior and appearance so that it fits naturally into the site’s layout.

This post is going to focus on how to use the new CardSpace CardTile and how to require user interaction during authentication using the InformationCard control. We’ll go into greater detail on how to secure your site using this new control in a future post.

As a side note, implementing the CardTile with the InformationCard control will prevent card selectors that don’t support CardTile, such as previous versions of CardSpace, from being able to log users into the web site. We are currently investigating how this behavior should be changed for a future release.

Implementing the CardTile with the InformationCard Control

So you have the “Simple Web Application with Information Card SignIn” sample from the SDK up and running and you want to see how you can customize the appearance of the control. Using the CardTile is a great starting point. Colin’s post describes the need to modify the OBJECT tag by hand. If you’re using the InformationCard control that comes as part of the framework, all this will be automatically done for you.

To implement the CardTile, simply open the solution, view the Default.aspx from the CustomUserNameCardStsHostFactoryWebSite project, view the properties for the InformationCard control, and look for DisplayType property.

By default this is set to None. Change it to CardTile and you’re done! Or if you prefer to edit the source XHTML by hand, simply add the DisplayType=”CardTile” attributes to the InformationCard control as shown below.

Save your changes, browse to the page in IE, and view the source code. You’ll see that the OBJECT tag has been generated to use the CardTile with the onclick event already wired for you. With one small change you’re taking advantage of the CardTile feature of CardSpace “Geneva”.

You can also change the default width and height of the CardTile by changing the DisplayTypeHeight and DisplayTypeWidth properties in VisualStudio.

Alternatively, if you choose to do this by editing the source XHTML, just add the DisplayTypeHeight and\or DisplayTypeWidth attributes to the control with the desired values.

After the changes have been saved and you browse to your site, you’ll see the OBJECT tag is rendered with the values you specified.

Requiring User Interaction

As a web developer, you may see fit to have users manually authenticate every time they come to your site. This can be easily be implemented by enabling the RequireUserInteraction on the InformationCard control.

Still using the “Simple Web Application with Information Card SignIn” sample, in VisualStudio view properties of the InformationCard control and locate the RequireUserInteraction property. As shown below the default behavior is set to False. Change this to True and you’re ready to go.

To do this by editing the source XHTML, add the RequireUserInteraction attribute to the control.

After you save your changes and visit the web site, you can see by the source HTML that the OBJECT tag now contains the requireUserInteraction parameter.

The “Geneva” Framework Makes Customizing Simple

As you can see the “Geneva” Framework allows developers to easily customize their website and take advantage of new card selector features like CardTile and RequireUserInteraction. Our goal is for web sites to be able to implement such features with as little effort possible.

Looking forward to your feedback!

Thank you,

Jason D. Shaw

Software Design Engineer in Test - “Geneva” Framework Team

The CardSpace “Geneva” Selection Experience

My name is Oren Melzer and I’m a developer on the CardSpace team. In this post, I am going to talk a bit about the newly designed selector in the new CardSpace “Geneva” beta.

Based on feedback from v1, one of our primary goals in designing the CardSpace “Geneva” selector was to give the user a simple, quick, and in-context card selection experience. Quite simply, users don’t want a lengthy or complex login experience; users want to quickly and easily access the site they’re trying to visit. With that in mind, the CardSpace “Geneva” selection experience was designed to be seamless. At a glance, users can see where their information is going and what data they’re sending. At the same time, they’re never more than a few clicks away from being authenticated.

The CardSpace “Geneva” selector uses Credential UI, a built-in Windows authentication mechanism that you may recognize from Remote Desktop Connection or smart card authentication. Credential UI allows CardSpace to operate in the context of the browser, so that the website the user is accessing is still visible.

The selector keeps users in context by appearing within the browser

Keeping it simple

When a user clicks the CardTile or the “log in” button on a webpage, the selector comes up showing all of the user’s cards that match the site’s policy. If the user has previously logged in to the site using CardSpace, the most recently used card will show up first and will be selected by default. All the user needs to do to log in is choose a card, authenticate to the Identity Provider (which may happen silently in the case of certificate or Kerberos backed cards), and click OK.

Users may also wish to review the personal data that they are submitting. To do this, the user simply clicks on “What information will be sent?” to review the display token returned by the Identity Provider. This functionality is equivalent to the “Preview” button in CardSpace v1.

"Show me what will be sent" allows users to review their data before submitting it.

“Always use this card at this site”

One new feature in the CardSpace “Geneva” beta is the ability to use a card automatically at a website. If the corresponding box is checked and the card is successfully submitted, CardSpace will automatically use the given card to log in to this site in the future, saving any credentials used. During subsequent logins to the same site, the user won’t be presented with the selector. Note that in the case of smart card backed cards, users will still have to authenticate to their smart cards. In the current beta, users can undo automatic card use by opening the CardSpace “Geneva” control panel applet and choosing “Delete all card history.”

Website developers should keep in mind that multiple users sometimes share the same Windows account and they may wish to log in to the same site using different cards. Websites may include an alternate object tag with the “requireUserInteraction” parameter set to true (see below) that allows the user to log in with a different card even if the user has chosen to always use a card. Should the user choose a different card, CardSpace “Geneva” will no longer use the previously chosen card automatically.

Information for developers

The following additional information may be useful for web developers:

· If the connection to a site does not use https, the selector displays a large warning advising the user not to submit sensitive data to the site.

If the connection is not over SSL, the user is warned not to send sensitive information.

· To mitigate spoofing attacks, the CardSpace selector limits the total length of the fully qualified domain name and scheme to 50 characters. The CardSpace selector will not be shown on sites with names longer than this limit. In corporate usage scenarios, system administrators may override this limit up to a maximum of 128 by setting a DWORD registry key at HKLM\Software\Microsoft\CardSpace\MaxHostNameLength.

Want to see the selector in action?

Go install CardSpace “Geneva” and try it out – if you don’t have a card, you can download an example card on the demo page.

Thanks,

Oren Melzer

Software Development Engineer

CardSpace “Geneva”

Simplified Trust Establishment using “Geneva”: Part 1

If you want your application to externalize user authentication to a Security Token Service (STS), you must consider:

• How are you going to identify your application to the STS?
• What type of security token are you expecting?
• What claims do you expect inside the token?
• What endpoint should your application’s users send requests for tokens?
• Do you want the STS to encrypt the tokens it issues (to ensure that others cannot inspect the tokens’ contents)?
• How can your application verify the origin and integrity of the tokens it receives (to ensure that the tokens were issued by the STS and were not tampered with in transit)?

Most or all of these questions must be answered in order to establish trust between the STS and your application.

Setting a trust relationship, as we mentioned above, implies interchanging different pieces of data such as digital certificates, uniform resource identifiers (URI), and endpoint addresses. Some of the feedback we received regarding “Geneva” Server’s predecessor, Active Directory Federation Services (AD FS), indicated that setting up these relationships was cumbersome and very error prone for users, especially when it came to typing URIs or choosing the right certificates to send across. Resulting errors are difficult to diagnose, especially if multiple organizations are involved.

Our goal with this series of 3 posts is to talk about how the features we have implemented in “Geneva” Server and “Geneva” Framework simplify trust establishment.

What does “establish trust” mean?

Let’s look at a couple of scenarios.

In the first scenario, suppose that a user needs to access your claims-aware application that requires a token from an STS inside your organization. As we mentioned before, the STS and the application have to trust each other:

The trust relationship between STS1 and Application1 needs to be configured at both ends:

• STS1 issues tokens for Application1. This means that the STS needs quite a bit of information about the application, including:
• The list of claims that it understands. Each claim type is represented as a URI.
• What type of token the application expects to be issued.
• The URIs identifying the application.
• Whether it expects the tokens encrypted and, if so, which certificate the STS should use for encryption.
• For certain scenarios, the URL of an endpoint at which the application is listening.
• Details about the supported protocols.
• Application1 accepts tokens issued by STS1. This means that the application also needs quite a bit of information about the STS, including:
• The list of claims that it may send.
• The certificate(s) with which the STS will sign its tokens.
• The token types (represented as URIs) that the STS supports.
• The protocols (represented as URIs) that the STS supports.
• For certain scenarios, a URI identifying the STS.
• For certain scenarios, the URL of an endpoint at which the STS is listening.
• Details about the supported protocols.

In the second scenario, you want to reach another claims-aware application that is deployed in a different organization; the most common deployment pattern is to use two STSs where one is in your organization and one is on your partner’s premises:

As in the previous scenario, two trusts must be configured so that:

• STS1 issues tokens for STS2.
• STS2 accepts tokens issued by STS1.
• STS2 issues tokens for Application2.
• Application2 accepts tokens issued by STS2.

The information that needs to be exchanged is the same as in the single STS scenario.

How does “Geneva” make this easier?

With the beta release of “Geneva” Server and Framework, we have simplified this experience and significantly reduced the number of manual steps needed:

• All the data required to establish trust (Federation Metadata) has been represented in a common format based on industry standards.
• “Geneva” Server publishes metadata at an endpoint and reads metadata exposed by other security token consumers or producers. Administrators setting trust only need to type in the metadata document URL and follow a simple wizard.
• Developers creating claims aware ASP.NET applications can use a tool that comes with “Geneva” Framework called “FedUtil”. This tool generates metadata of the application and imports metadata from the STS.

In the next two posts, we will talk in more detail about how to configure ASP.NET applications to accept tokens issued by an standards-based STS (such as “Geneva Server”) using “Geneva” Framework and how to create trust relationships with Identity Providers and Relying Parties using “Geneva” Server.

We look forward to receiving your valuable feedback.

Thanks!

Ramiro Calderón

Software Design Engineer in Test

“Geneva” team

New in CardSpace "Geneva": the CardTile

Hi, my name is Colin Dellow and I'm a developer on the CardSpace team.

In Windows CardSpace "Geneva" beta, we've added a visual component to the OBJECT tag that we call the "CardTile." The CardTile shows the user the last card they submitted to a given site or the purple Information Card icon if they have never sent a card. Showing the user an image of the card they last submitted assures them it's the same site that they are returning to and that they have previously submitted a card to it.

Websites must explicitly opt into this feature; existing pages that use the object tag will continue to work as they always have, opening CardSpace for card selection. Even though the CardTile control is rendered in the page, the images shown by the control are not accessible to the page – it is not even possible for the page to know whether the image being shown is the Information Card icon or the user's most recent card.

Want to try it out?

Go install CardSpace "Geneva" and try it out – if you don't have a card, you can download an example card on the demo page.

Want to use it on your webpage?

To use the CardTile feature you will need to add the new displayType parameter to the OBJECT tag:

Stay tuned for future posts that describe how to do this using "Geneva" Framework, which also provides support for processing the token returned by CardSpace.

On their first visit, users will see a purple "I" CardTile indicating that they have never submitted a card to the site:

After submitting a card to the site, the tile will render differently for the user on subsequent visits:

This image tells the user that they have visited the site before and have most recently used the Fabrikam card.

A few notes:

• The decision of which card to show isn't really as simple as the last used card – in fact, it is the last used card that matches the site's current policy requirements
• The onclick attribute is an optional attribute; if set, the user's cursor will turn into a hand when it hovers over the CardTile, and the specified JavaScript will be executed when the user clicks
• The default size of the CardTile is 120 pixels by 80 pixels, but this can be overridden:

  <FORM METHOD='POST' ACTION='processingPage.aspx'>     <OBJECT ID='infocard'              TYPE='application/x-informationCard'             ONCLICK='submit();'>         <PARAM NAME='requiredClaims'                VALUE='http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress' />         <PARAM NAME='displayType'                 VALUE='CardTile' />         <PARAM NAME='width' VALUE='60' />        <PARAM NAME='height' VALUE='40' />     </OBJECT> </FORM>

We have only shipped support for the CardTile in the Internet Explorer plugin that comes with CardSpace "Geneva."  In a separate post, we will document how other browser add-ons can also access this functionality in the beta.

Thanks,

Colin

“Geneva” Server Beta

We’re excited to tell you more about the beta release of “Geneva” Server.  In this post we’ll talk a bit about what “Geneva” Server is, as well as discuss the features of “Geneva” Server.  As you may have read already, “Geneva” Server is one component of the broader “Geneva” claims based access (CBA) platform.  The other components are the “Geneva” Framework for developers and Windows CardSpace “Geneva”.  All of the “Geneva” components are available for download at our Connect site. 

This beta release of “Geneva” Server is not yet feature complete, and is not intended for use in a production environment.  We’re looking forward to your early feedback on “Geneva” Server’s features and on what you’d like to see in future releases. 

What is Geneva Server?

“Geneva” Server is a security token service (STS) that enables Active Directory to be an identity provider in the claims based access platform. Specifically, “Geneva” Server solves several identity problems for information technology (IT) professionals:

• Use the Claims Based Access Platform: Deploying “Geneva” Server enables an organization’s applications to use the claims based access platform and avoid fixed dependencies on specific authentication, authorization and directory service technologies. 

•  Reduce Duplicate Accounts: “Geneva” Server reduces the need for duplicate accounts and other credential management overhead by enabling federated single sign-on (SSO) for users in other organizations. 

•  Reduce Number of Passwords for Users: “Geneva” Server enables an organization’s users to consume outsourced hosted services without needing additional credentials.

• Centrally Manage Application Authentication: “Geneva” Server enables IT professionals to easily change the authentication methods for enterprise applications as security policies change.

• Manage Communication of User Information: “Geneva” Server enables IT professionals to easily manage the user specific information that is sent to each enterprise application.

• Normalize Directory Service Access: “Geneva” Server enables IT professionals to avoid line-of-business applications burdening the corporate directory services in unpredictable ways due to poorly constructed, processor-intensive requests.

Additional “Geneva” Server Features

Simplified trust establishment: “Geneva” Server uses industry standard metadata formats for establishing trust between federation partners. The “Geneva” Server administration console allows administrators to establish trust by simply entering the partner’s trust metadata URL. This simplifies and improves the trust establishment experience for administrators by reducing the number of manual steps involved.

Information Cards: Information Cards provide an improved log-in experience, and the issuance of Information Cards allows “Geneva” Server to act as an identity provider that can be used with Windows CardSpace.  “Geneva” Server includes a Web application where Active Directory users can obtain managed Information Cards, as well as administrative capabilities for branding these Information Cards.  

Identity delegation:  Web applications in a multitier architecture often call infrastructure services to access common data or functionality. It is important for these infrastructure services to know the identity of the original user so that the service can make authorization decisions and perform auditing. “Geneva” Server allows an authorized front-end Web application to impersonate its users to the infrastructure service.  When using “Geneva” Server, the infrastructure service knows that the front-end Web application is serving as the user’s delegate. In addition, “Geneva” Server does not require that an account exist in Active Directory for the impersonated user.

Multiple supported authentication methods:  “Geneva” Server supports multiple authentication methods at the STS. Users will be able to authenticate with user name/password, the Kerberos authentication protocol, client X.509 certificates, and Information Cards. Administrators have fine-grained control over the specific authentication methods that are supported, to suit their security policies. In addition, “Geneva” Server supports responding to requests for particular authentication methods, such as smart-cards.  This enables applications that are protected by “Geneva” Server to easily step-up to smart-card authentication for particular operations. 

Interoperable by design:  “Geneva” Server supports multiple, industry-standard, interoperable protocols such as WS-Federation, WS-Trust and other WS-* security standards. In addition, “Geneva” Server supports identity provider functionality in the Web SSO profile of the SAML 2.0 protocol.   This broad base of protocol support makes it possible for “Geneva” Server to work with a variety of identity products from other vendors that support these protocols.

Give us your feedback!

Please give us your feedback and tell us what you think. The set of features above provides only a quick overview of what “Geneva” Server can do.  More posts are coming to discuss these features in detail, and we look forward to a conversation on how “Geneva” Server can solve your identity challenges.  Thanks,

-  The “Geneva” Server Team

Microsoft “Geneva” Framework

We’re excited to announce the Beta release of Microsoft Code Name “Geneva” Framework. This framework is the successor to our previous beta release code named “Zermatt”.

This release, in addition to adding some new features, polishes up many of the existing features that were available in the previous Zermatt release. Our primary motivation for the changes was to simplify the developer experience and better align it with existing technologies. In this post we’re going to discuss some of the changes in this release. Future posts will talk about the features below in greater detail.

Before delving into the details of the framework, we’d first like to point out that the framework is part of a larger wave of products known as “Geneva.” If you haven’t already done so, please be sure to visit http://www.microsoft.com/geneva for more information.

The following document provides a detailed overview of all the changes that were made between the previous release and this release. However, for purposes of keeping this blog post reasonably short, we’ll give a high level overview of some of these changes.

The New Claims Model

This release (as with the previous release) introduces a new claims model. This new model combines the claims world with the IIdentity/IPrincipal world that developers are familiar with into one concept called the IClaimsIdentity/IClaimsPrincipal that is fully compatible with the IIdentity/IPrincipal world. Furthermore, we’ve also replaced ClaimsPrincipal.Current with Thread.CurrentPrincipal as the mechanism by which an application accesses claims about the caller.

In this release, we’ve changed the type of the issuer of a claim, Claim.Issuer, to string instead of a collection of claims to simplify handling, and make the issuer identification independent of the credential that is used to sign issued security tokens. To support the Claim.Issuer as string, we have added a translation mechanism that supports converting an issuer’s signing credential (usually an X.509 certificate) into an issuer’s name. This mechanism is implemented by the IssuerNameRegistry class and is fully extensible so that developers can provide their own implementation for this translation. The framework itself ships with a simple, configuration-based translation implementation.

We’ve also introduced a new data field holding the original issuer of a claim: Claim.OriginalIssuer. This is useful for claims that traverse through a federated chain.

Claims Authentication

One of the pain points with our previous Beta was with not knowing where to authenticate the set of claims representing the user. The concept of authenticating the user existed in multiple places and it was hard to figure out where such an operation should be performed. To address this, we’ve introduced an easy to use extensibility model called the ClaimsAuthenticationManager as the one place to do authentication.

Token Handling Improvements

In this release, we’ve expanded the role of TokenHandlers. If you recall from our previous Beta, TokenHandlers were only used for processing SAML1.1, and SAML2.0 tokens. In this release however, we’ve expanded this model for all token types, including Username/Password, X509Certificates, Kerberos, Secure Sessions in WCF (SCT’s), and HttpCookies. This makes the programming model simpler and more consistent.

Authentication Module Improvements

One of the more prominent changes that we’ve made is to our ASP.NET relying party (RP) processing pipeline. In the previous release, we implemented a single Federated Authentication Module (FAM) that did all the heavy lifting whenever a token arrived at an ASP.NET RP. In this release, we’ve broken up the FAM into a set of authentication modules, namely the SessionAuthenticationModule, the WSFederationAuthenticationModule, and the ClaimsPrincipalHttpModule.  These independent modules all work together to make the processing pipeline easier to understand, and provide a much better compatibility story with ASP.NET’s FormsAuthentication and UrlAuthorization modules.

Security Token Service (STS) Pipeline Improvements

We’ve improved the pipeline around building Security Token Services. In addition we’ve also added better support for an asynchronous pipeline.

Federation Establishment with an STS

Wouldn’t it be nice if there were an easy way to establish a trust relationship between your application and the SecurityTokenService it receives security tokens from? We’ve now included a new tool called FedUtil.exe to make this process easier.

Geneva Token Service

In some federation scenarios, an existing application can be written to accept, for example, a SAML token, but may need to translate this to a Windows account.

The “Geneva” Token Service is a Windows NT service that gets installed as a part of the Geneva Framework. This service can translate the incoming SAML token into Windows identities that can be then used by your application to authorize the caller and to access other services using Windows authentication. With this Beta, whenever your STS issues you a SAML token that has a UPN claim in it, the Geneva Framework has functionality that will automatically convert this token into a WindowsToken for you.

ASP.Net control for Windows® CardSpace “Geneva” Beta

The “Geneva” framework continues to make it easier for developers to write an ASP.NET relying party that works seamlessly with Information Cards. Our Information Card SignIn control now exposes new properties, like Card Tile and RequireUserInteraction that work well with this new Beta version of Windows® CardSpace “Geneva”.

Give us your feedback!

Please give us your feedback and tell us what you think. The features described above provide just a glimpse of the changes that went into this release. We’ve tried hard to make the programming model simpler, and better aligned with some of the existing ASP.NET/WCF environments.

-  The “Geneva” Framework Team