Identity and Access Control
Most server applications care about user identity. Some simply need to distinguish one user from another for practical purposes such as managing a shopping cart. Others need to further identify, authenticate, and authorize the user to access restricted features or high-value resources. There are many ways of approaching this on Windows Server 2008.
Applications designed to service the enterprise can leverage the rich authentication and authorization infrastructure provided by Windows Server 2008, using Active Directory® Domain Services (AD DS) to manage user accounts and provide single sign-on (SSO) via Kerberos for those users to all applications in the enterprise. Windows Server 2008 provides an access control list (ACL) on each file, and server applications can impersonate clients before opening high-value files to automate client authorization. You can create groups to represent roles when you need simple role-based access control (RBAC), and for more involved RBAC scenarios, Windows Authorization Manager (AzMan) allows your application to focus on authorizing operations, while allowing an administrator to map groups, roles, and tasks onto those operations.
While Kerberos is a great way to authenticate users inside an enterprise, it hasn’t proven practical for authenticating users in the cloud. Internet-facing applications traditionally have used other means, such as ASP.NET Forms Authentication and Membership features to implement simple password-based authentication. Most of these systems use either Microsoft SQL Server® or Active Directory Lightweight Directory Services (AD LDS) to store user accounts, depending on whether SQL or LDAP (Lightweight Directory Access Protocol) is the preferred programming experience.
If the identity story I’m telling so far seems fragmented, you’re right. There’s one way of dealing with users who come from our enterprise, and a completely different way of dealing with users who come from the cloud or from other organizations. And frankly, issuing accounts for external users is painful to implement and manage, and it’s error prone. When does a partner organization let you know that one of its employees has left the company and should no longer have access to your application? The solution to these and other problems revolves around claims and federated identity.
By building claims-aware Web applications and services, developers can externalize authentication, as well as authorization and personalization to a large degree. Instead of implementing these features directly, a claims-aware system accepts a security token signed by a trusted identity provider, and uses the claims inside that token to discover identity attributes for the user. Claims introduce a level of indirection that decouples the application from the mechanisms used to authenticate the user, as well as the identity stores where the user’s attributes are stored. This allows the application to focus on business logic and avoid dealing with the details of identity management. Single sign-on and the ability to federate identity across technological and/or organizational boundaries follow naturally. Federation servers can be provisioned in each realm to authenticate the user in the most natural way possible and provide a security token to the application that includes only the claims the application needs to do its job. Like Kerberos tickets, security tokens use strong cryptographic techniques for security. But security tokens are more flexible than Kerberos tickets, and can be easily extended to hold any type of claim — from user names, groups, roles, and e-mail addresses to more sophisticated data structures.
Active Directory Federation Services (AD FS) is the currently shipping federation server. “Geneva Server” is the code name for the next generation federation server that is in beta 2 as of this writing.
“Geneva” is the next generation of claims-based infrastructure. It is an open platform that provides simplified user access and single sign-on for on-premises and cloud-based applications in the enterprise, across organizations, and on the Web. There are three parts to “Geneva,” which I’ll discuss in turn.
“Geneva” Framework is a managed library that implements the plumbing behind federation protocols such as WS-Federation (passive) and WS-Trust. Developers can use this library to build claims-aware Web services and browser-based Web applications, as well as custom identity providers.
“Geneva” Server, built on top of “Geneva” Framework, is the next-generation federation server that will eventually replace AD FS. Besides servicing existing AD FS-enabled Web applications, “Geneva” Server issues tokens that rich clients can send to Web services. AD and AD LDS are supported out of the box as attribute stores (similar to AD FS), with the addition of SQL Server. Developers can extend “Geneva” Server by writing managed code to implement new attribute stores as well. With its sophisticated rules engine, administrators can define rules to extract identity attributes from one or many of these stores for any given user, making “Geneva” Server more flexible than its predecessor, AD FS. “Geneva” Server is designed to issue information cards, which help users easily navigate complex federation trust paths.
“Geneva” CardSpace is the next version of Windows CardSpace™, which originally shipped with Windows Vista®. This new version has been completely rewritten in native code, resulting in a much lighter client download experience (on the order of 5 MB). The user experience is much simpler as well. Built on the Credential UI built into Windows, “Geneva” CardSpace feels more natural to users as a credential selector.
Other ResourcesActive Directory
The .NET Developer's Guide to Directory Services Programming
Active Directory Lightweight Directory Services
Authorization Manager (AzMan)
Active Directory Federation Services
A Developer's Introduction to Active Directory Federation Services
Microsoft Code Name "Geneva"
"Geneva" White Papers
"Geneva" Developer Center