Announcing Windows Identity Foundation (WIF) Release Candidate

We are happy to announce that Release Candidate (RC) of Windows Identity Foundation (previously known as Geneva Framework) is available NOW!

It comes with lots of great new features and with comprehensive set of samples in the WIF SDK.

This release contains major updates and new features such as:

·         Refactored WSTrustClient as WSTrustChannelFactory and WSTrustChannel

·         Extended tracing functionality for better diagnosibility

·         Unifying SAML end points through WrappedTokenAuthenticator

·         Crypto agility

·         Bootstrap tokens availability through ClaimsIdentity

·         Security token cache updates to support session mode for ASP.NET cookies

·         FedUtil leveraged for control-based applications

We have heard your valuable feedback and have made changes to some of the features existed in Beta-2. Refer to the Changes Between Beta-2 and RC whitepaper for the list of major changes made in this RC. Also, the updated WIF Whitepaper provides you a conceptual overview on WIF features and scenarios.

You can get the WIF RC Setup packages here.

This RC is targeted for Win7, W2K8 R2, W2K8, and Vista platforms for both 32-bit and 64-bit architecture. Note that this release does not have W2K3 platform support, which will come later.

Move onto WIF RC and extend the great new WIF features!

How Windows Identity Foundation helps with access control and what is its relationship to AzMan

The new Identity and Access products wave from Microsoft brings a new, claims-based, approach to identity and access space. This new approach is based on the principles defined by the Identity Meta-System. Windows Identity Foundation (WIF), which is part of this new Identity and Access products wave, gives applications a much richer and flexible way to deal with identities by introducing claims-based identity concept. WIF also decouples the application business logic from the authentication and identity attributes lookup details by externalizing these processes into a component called security token service (STS). The primary goal of this new Identity and Access products wave is to enable this new, claims-based, identity and access model and make it as easy as possible for existing and new applications to leverage the exciting capabilities that this model provides.

One of the most important aspects of every identity and access platform is to enable applications to protect their resources from unauthorized use. Given the richness and flexibility that the claims-based identity model allows, it is even more important than ever to provide a guidance and model that allows applications to deal with claims-based identities with respect to controlling access to their resources. For this purpose, the WIF provides a new API that allows applications to deal with authorization related activities. This new API is centered around ClaimsAuthorizationManager class. The primary goal of this API is the same as of Authorization Manager, a component of Windows operating system, sometimes referred to as AzMan – to allow applications externalize the details of the access control management and authorization policies evaluation from their application logic. The API is completely .NET based, eliminating a need for managed layer wrappers to access a native API from the .NET applications. The API provides similar functionality to what AzMan AccessCheck API represents. However, there are important differences between the API that AzMan provides and the new ClaimsAuthorizationManager methods. As already mentioned, unlike AzMan, the ClaimsAuthorizationManager is purely .NET API making it easier to understand and use than managed wrappers around COM+ API that AzMan provides. But the biggest difference is that fact that AzMan is tied to a particular authorization policy format, does not natively support claims-based identities and its decision engine is fixed. In contrast, ClaimsAuthorizationManager directly leverages the claims-based identity concept and allows different implementations to be plugged behind its uniform authorization interface, as explained more below.

Given the flexibility and richness of the claims-based identity model, there is no single model for managing access to resources that would fit all the needs and scenarios enabled by the claims-based architecture. Because of this, the ClaimsAuthorizationManager, unlike AzMan, is not tied to a particular authorization policy implementation. Instead, the ClaimsAuthorizationManager serves as a framework into which various authorization policy implementations can be plugged in. This allows the developers and IT administrators to choose the right authorization policy mechanism for the given deployment and even replace the authorization policy implementation with a new one without affecting existing applications.

However, given the focus of the new Identity and Access products wave on enabling the claims-based access to applications and providing the necessary infrastructure to allow the authentication to be externalized from the applications, the WIF does not provide an authorization policy plug-in for the ClaimsAuthorizationManager. This means that, even though the authorization API is delivered and available through WIF, it cannot be used by applications at runtime without providing a concrete implementation of the authorization policy plug-in. From this perspective, the ClaimsAuthorizationManager, unlike AzMan, is not a complete out of the box authorization solution.

One of our goals, after we deliver this new Identity and Access products wave, is to explore one or more such authorization policy plug-ins that will integrate with the ClaimsAuthorizationManager API provided by WIF and allow the claims-based identity architecture to be fully leveraged when making access control decisions while being interoperable and based on industry best practices. Such authorization plug-in implementation together with ClaimsAuthorizationManager API in WIF can be thought of as a next generation of AzMan that is completely based on the Identity Meta-System principles.

With all all said, we encourage all developers that use or plan to use Windows Identity Foundation in their projects to leverage the new authorization API provided by the ClaimsAuthorizationManager class by moving their authorization logic from the application logic into a concrete implementation of the ClaimsAuthorizationManager that can then be used whenever an authorization decision needs to be made as part of the application’s business logic. By doing so, your application will allow the authorization logic to be externalized from the business logic and thus simplifying the application implementation. In the end this will give the users and administrators of the application sufficient flexibility to be able to change the underlying authorization logic based on their needs and provide the necessary foundation to enable the central management of authorization policies across the enterprise.

AD FS v2.0 Passes Liberty Alliance SAML 2.0 Interoperability Testing

Interoperability of identity systems is an important consideration for a large percentage of customers. With this in mind we chose to participate in 8 weeks of SAML 2.0 testing, which is was conducted by the Drummond Group Inc.  As previously announced, we entered testing with three profiles, IdP Lite, SP Lite and EGov 1.5.

Today the test results were made public , and we are thrilled to announce we have passed.  We are very proud of this accomplishment, and all the hard work the AD FS team did to make this happen.

We would like to thank the other test participants; Entrust, IBM, Novell, Ping Identity, SAP, and Siemens. They where all great to work with, and demonstrated a real commitment to ensuring all of our products work together for customers.

Testing was done in a full matrix, meaning all tests pass with each vendor.  This meant 8 to 12 tests (depending on the profile) with each of the 7 solutions, with AD FS acting as both IdP and SP; resulting in about 150 tests to pass! As you can imagine there were a few nights the team didn’t get much sleep.  If you would like to dig into the details of what was tested, the test plan is available from the Liberty site.

Additional articles about the Liberty Alliance Testing:

·         PRN Newswire - Entrust, IBM, Microsoft, Novell, Ping Identity, SAP and Siemens Pass Liberty Alliance SAML 2.0 Interoperability Testing

·         Computerworld - Microsoft passes its first SAML 2.0 interoperability test

Identity Samples available on Code Gallery

Our friends in the DPE team recently published on Code Gallery three Windows identity Foundationsamples:

·         FabrikamShipping. This is a fairly complete example of how to use the Windows identity Foundation for addressing common tasks in the development of web solutions: accepting identities from an external identity provider, driving the UI using claims, invoking back-end WCF services via delegated authentication, handling claims based authorization and so on. The sample is based on the scenario described in Kim’s Cameron PDC08 session. You can download the sample from here; a detailed description is available here.

·         ClaimsDrivenModifierControl. This is a sample ASP.NET control that demonstrates how you can take advantage of claims for driving the behavior of your web UX without the need of writing any code! You can download the sample from here; a detailed description is available here; finally, if you want to see the control in action a screencast is available here.

·         SecurityTokenVisualizerControl. This a very simple ASP.NET control that can help you to debug your websites secured with the Windows identity Foundation, by allowing you to inspect identity information in the current context such as claims list, raw XML of the incoming token, signing certificates and more. You can download the sample from here; a detailed description is available here

All examples come with a handy installer which verifies if your system complies with the necessary prerequisites, and helps you to download & configure what you are missing. Have fun with the samples, we look forward to your feedback!

CardSpace Geneva Beta 2 Samples Package

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.

Official Name for "Geneva"

This Monday, Microsoft made several announcements at the Worldwide Partner Conference in New Orleans.  Among these announcements were the official names for the Geneva products currently in Beta.

The three components of Microsoft “Geneva” have the following names:

·         Active Directory Federation Services  –  formerly known as “Geneva” Server. Active Directory Federation Services (AD FS) enables Active Directory to be an identity provider in the claims based access platform.  AD FS provides end users a single sign-on experience across applications, platforms and organizations and simplifies identity management for IT Pros by reducing duplicate accounts. 

·         Windows Identity Foundation – formerly known as “Geneva” Framework. Windows Identity Foundation (WIF) offers sets of APIs for ASP.NET and WCF developers to build claims-aware applications and make them federation capable. This API set covers both building relying party applications and federation services that can issue security tokens.

·         Windows CardSpace – same as current version. Windows CardSpace enables managed and native applications to participate in the claims-based access platform. Windows CardSpace empowers end-users to have better control of their identity and allows administrators to setup streamlined single sign-on access.

This news is part of our Business Ready Security strategy to help both partners and customers 1) protect everywhere and access anywhere, 2) integrate and extend security across the enterprise, and 3) simplify the security experience and manage compliance.

For more information about these announcements and others that were made, check out the Microsoft Forefront 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”