patterns & practices Developer Center

September  2011

Summary

Imagine a world where you don't have to worry about authentication. Imagine instead that all requests to your application already include the information you need to make access control decisions and to personalize the application for the user.

In this world, your applications can trust another system component to securely provide user information, such as the user's name or email address, a manager's email address, or even a purchasing authorization limit. The user's information always arrives in the same simple format, regardless of the authentication mechanism, whether it's Microsoft® Windows® integrated authentication, forms-based authentication in a web browser, an X.509 client certificate, or something more exotic. Even if someone in charge of your company's security policy changes how users authenticate, you still get the information, and it's always in the same format. This is the utopia of claims-based identity that A Guide to Claims-Based Identity and Access Control describes.

This is the second edition of this popular guide. It has been extensively updated to include new features and changes to the underlying technologies; and extends the coverage to encompass Windows Azure® Access Control Service, REST-based service authentication, and the use of claims-based authentication in Microsoft SharePoint® 2010. As you'll see, claims provide an innovative approach for building all types of applications that must authenticate and authorize users. 

This edition also has a set of associated Hands-on-Labs that will help you to better understand the way that the example application works, how you can extend it with additional functionality, and how you can implement some of the advanced scenarios described in the guide.

Contents

Overview

Community

Future Plans

Feedback and Support

Authors and Contributors

Related Titles

Overview

This book gives you enough information to evaluate claims-based identity as a possible option when you are planning a new application or making changes to an existing one. It is intended for any architect, developer, or information technology (IT) professional who designs, builds, or operates Web applications and services that require identity information about their users.

Although claims-based identity has been possible for quite a while, there are now tools available that make it much easier for developers of Windows-based applications to implement it. These tools include the Windows Identity Foundation (WIF), Microsoft Active Directory® Federation Services (ADFS) v2, and Windows Azure Access Control Service (ACS). This book shows you when and how to use these tools in the context of some commonly occurring scenarios.

Contents of the Guide

An Introduction to Claims explains what a claim is and provides general rules on what makes good claims and how to incorporate them into your application. It's probably a good idea that you read this chapter before you move on to the scenarios.

Claims-Based Architectures shows you how to use claims with browser-based applications and smart client applications. In particular, the chapter focuses on how to implement single sign-on for your users, whether they are on an intranet or an extranet. This chapter is optional. You don't need to read it before you proceed to the scenarios.

Claims-Based Single Sign-On for the Web and Windows Azure is the starting point of the path that explores the implementation of single sign-on and federated identity. This chapter shows you how to implement single sign-on and single sign-out within a corporate intranet. Although this may be something that you can also implement with Integrated Windows Authentication, it is the first stop on the way to implementing more complex scenarios. It includes a section for Windows Azure™ technology platform that shows you how to move the claims-based application to the cloud.

Federated Identity for Web Applications shows how you can give your business partners access to your applications while maintaining the integrity of your corporate directory and theirs. In other words, your partners' employees can use their own corporate credentials to gain access to your applications.

Federated Identity with Windows Azure Access Control Service is the start of a parallel path that explores Windows Azure Access Control Service (ACS) in the context of single sign-on and federated identity. This chapter extends the scenarios described in the previous chapter to enable users to authenticate using social identity providers such as Google and Windows Live® network of Internet services.

Federated Identity with Multiple Partners is a variation of the federated identity scenario that shows you how to federate with partners who have no issuer of their own as well as those who do. It demonstrates how to use the ASP.NET MVC framework to create a claims-aware application.

Federated Identity with Multiple Partners and Windows Azure Access Control Service extends the scenarios described in the previous chapter to include ACS to give users additional choices for authentication that include social identity providers such as Google and Windows Live.

Claims Enabling Web Services is the first of a set of chapters that explore authentication for active clients rather than web browsers. This chapter shows you how to use the claims-based approach with web services, whereby a partner uses a smart client that communicates with identity providers and token issuers using SOAP-based services.

Securing REST Services shows how to use the claims-based approach with web services, whereby a partner uses a smart client that communicates with identity providers and token issuers using REST-based services.

Accessing REST Services from a Windows Phone Device shows how you can use claims-based techniques with Windows Phone™ wireless devices. It discusses the additional considerations that you must take into account when using claims-based authentication with mobile devices.

Claims-Based Single Sign-On for Microsoft SharePoint 2010 begins a path that explores how you can use claims-based identity techniques with Microsoft SharePoint 2010. This chapter shows how SharePoint web applications can use claims-based authentication with an external token issuer such as ADFS to enable access from both internal locations and externally over the web.

Federated Identity for SharePoint Applications extends the previous chapter to show how you can use federated identity techniques to enable users to authenticate using more than one identity provider and token issuer.

Audience Requirements

Although applications that use claims-based identity exist on many platforms, this book is written for people who work with Windows-based systems. You should be familiar with the Microsoft .NET Framework, ASP.NET, Windows Communication Foundation (WCF), Microsoft Active Directory®, and Microsoft Visual C#®.

System Requirements

You can either run the samples that illustrate the scenarios in the guide on your own system or you can create a realistic lab environment. Running the scenarios on your own system is very simple and has only a few requirements. These are the system requirements for running the scenarios on your system:

• Microsoft Windows Vista® SP1, Windows 7, Windows Server 2008 (32-bit or 64-bit), or Windows Server 2008 R2 (32-bit or 64-bit)
• Microsoft Internet Information Services (IIS) 7.0 or 7.5
• Microsoft .NET Framework 4.0
• Microsoft Visual Studio® 2010 (excluding Express editions)
• Windows Azure Tools for Microsoft Visual Studio
• Windows Identity Foundation

Running the scenarios in a realistic lab environment, with an instance of Active Directory Federation Services (ADFS) and Active Directory, requires an application server, ADFS, Active Directory, and a client system. Here are their system requirements.

Note: The example code for this guide and for the associated Hands-on-Labs was built using the Windows Azure Tools for Visual Studio version 1.3 (March 2011), and has also been tested using version 1.4 (August 2011) of the tools. The Dependency Checker utility provided with the examples will check for the presence of either the version 1.3 or version 1.4 release of the tools. If you have version 1.4 installed, you will be prompted to migrate the solutions to this version when you open them in Visual Studio.

Application Server

The application server requires the following:

• Windows Server 2008 or Windows Server 2008 R2
• Microsoft Internet Information Services (IIS) 7.0 or 7.5
• Microsoft Visual Studio 2010 (excluding Express editions)
• .NET Framework 4.0
• Windows Identity Foundation

ADFS

The ADFS server requires the following:

• Windows Server 2008 or Windows Server 2008 R2
• Microsoft Internet Information Services (IIS) 7.0 or 7.5
• .NET Framework 4.0
• Microsoft SQL Server® 2005 or 2008 Express Edition

Active Directory

The Active Directory system requires Windows Server 2008 or Windows Server 2008 R2 with Active Directory installed.

Client Computer

The client computer requires Windows Vista or Windows 7 for active scenarios. Passive scenarios may use any web browser as the client that supports HTTP redirection.

Community

This guide, like many patterns & practices deliverables, is associated with a community site. On this community site, you can post questions, provide feedback, or connect with other users for sharing ideas. Community members can also help Microsoft plan and test future guides, and download additional content such as extensions and training material.

Future Plans

Additional content and plans will be published to the community site.

Feedback and Support

Questions? Comments? Suggestions? To provide feedback about this guide, or to get help with any problems, please visit the Community site. The message board on the community site is the preferred feedback and support channel because it allows you to share your ideas, questions, and solutions with the entire community. A Guide to Claims-based Identity and Access Control is a guidance offering, designed to be reused, customized, and extended. It is not a Microsoft product. Code-based guidance is shipped "as is" and without warranties. Customers can obtain support through Microsoft Support Services for a fee, but the code is considered user-written by Microsoft support staff.

Authors and Contributors

This guide was produced by the following individuals:

• Program and Product Management:  Eugenio Pace
• Subject Matter Experts: Dominic Betts, Dominick Baier, Vittorio Bertocci, Keith Brown, and Matias Woloski
• Development: Scott Densmore, Federico Boerr and Nicolas Paez
• Test team: Masashi Narumoto, Rathi Velusamy and RaviShankar Chemudupati
• Edit team: RoAnn Corbisier, Colin Campbell (Modeled Computation LLC), Roberta Leibovitz (Modeled Computation LLC), Alex Homer, Nancy Mitchell, and Tina Burden
• Book design and illustrations: John Hubbard (eson), Ellen Forney and Veronica Ruiz
• Release Management: Richard Burte

We want to thank the customers, partners, and community members who have patiently reviewed our early content and drafts. Among those, we want to highlight the exceptional contributions of Zulfiqar Ahmed, Michele Leroux Bustamante (IDesign), Pablo Mariano Cibraro (Tellago Inc), Hernan DeLahitte (DigitFactory), Pedro Felix, Tim Fischer (Microsoft Germany), Mario Fontana, David Hill, Doug Hiller, Jason Hogg, Ezequiel Jadib (Southworks), Brad Jonas, Seshadri Mani, Marcelo Mas, Vijayavani Nori, Krish Shenoy, Travis Spencer (www.travisspencer.com), Mario Szpuszta (Sr. Architect Advisor, Microsoft Austria), Chris Tavares, Peter M. Thompson, Todd West, Robert Bogue, Jonathan Cisneros, Shy Cohen, David Crawford, Laura Hunter, Chris Keyser, Jason Lee, Alik Levin, Nicolas Paez, Brian Puhl, Paul Schaeflein, Ken St. Cyr, Venky Veeraraghavan, Bill Wilder, Daz Wilkin, Jim Zimmerman, Steve Peschka, and Christian Nielsen.

Finally, we want to thank Stuart Kwan and Conrad Bayer from the Identity Division at Microsoft for their support throughout, and everyone who participated in our CodePlex community site.

Related Titles

• Basic Security Practices for Web Applications
• Improving Web Services Security
• p&p Windows Azure Guidance Project

Published: September 27, 2011

This white paper describes how Web applications in Microsoft SharePoint Server 2010 can use claims-based authentication to provide authenticated access to entities that are external to your organization and enable multiple authentication types within a single zone.

It also provides many of the details related to setting up a trust configuration, an explanation of runtime considerations and management, configuration details, and programmatic implementations or use of the extensibility points that turn federated access into a federated SharePoint Server 2010 business solution. In addition, this white paper provides guidance in the following areas:

•           Overview of Claims-based Identity in SharePoint Server 2010
•           SharePoint Server 2010 with Active Directory Federation Services 2.0
•           Creating Multiple Claims Authentication Web Applications in a Single SharePoint Server 2010 Farm
•           Setting the Login Token Expiration Correctly for SharePoint Server 2010 SAML Claims Users
•           Creating a Custom Claims Provider
•           Migration of Users in Classic Mode to Trusted Provider Claims
•           How to Enable Tracing for SharePoint Server 2010 Claims
•           Trusted Identity Providers and User Profile Synchronization
•           Using Audiences with Claims-Based Sites
•           Implications of Claims Mode Authentication on Service Applications
•           Service Applications and the C2WTS
•           Using Active Authentication for Custom Development in SharePoint Server 2010 Claims Authentication Web Applications

Download the white paper

 ( Please forgive the typos.  Anywhere ADFS was in the paper was find-replaced with AD FS broke the code examples and powershell.  I am working to get that revised currently.  Also special thanks to a couple of the authors/contributers who are missing from the credits -  Adam Conkle and Tyler Durham. ) 

Getting Started with AzMan
Programming AzMan – (Code Sample)
AzMan in the Enterprise – (Code Sample)

AzMan on Windows Server Code Name “Longhorn” and Windows Vista

(Thanks to Donovan Follette https://blogs.msdn.com/donovanf/ for this great content! )

]]> https://docs.microsoft.com/archive/blogs/dc995/how-to-stswindows-authentication-with-adamad-roles-in-azman-with-wcf Fri, 16 Feb 2007 16:40:00 GMT https://blogs.msdn.microsoft.com/dc995/2007/02/16/how-to-stswindows-authentication-with-adamad-roles-in-azman-with-wcf/  

 I ran across the following article by Sam Gentile that may be of interest to you AzMan-ers... check it out.

https://codebetter.com/blogs/sam.gentile/archive/2006/05/26/145540.aspx

Regards,
David

]]> https://docs.microsoft.com/archive/blogs/dc995/custom-authentication-with-azman-a-note-on-sid-datatype Wed, 23 Aug 2006 13:42:00 GMT https://blogs.msdn.microsoft.com/dc995/2006/08/23/custom-authentication-with-azman-a-note-on-sid-datatype/ There are  multiple ways to implement custom authentication with AzMan but if you are using an approach with custom SIDs (security identifiers), you should be aware of the data type for a SID.

Each sub authority is of type ULONG (32 bit) numeric which means numbers less than 4294967295 and no hex characters. So the format recommended for a Custom SID is S-1-9-1-1 through S-1-9-4294967295-4294967295. There is no validation based on sub authority either e.g. S-1-5 isn’t evaluated in AzMan any different from any other but you run the risk of collision with well known SIDs or prod AD SIDs . ( Thanks Sudheer! )

 

Regards,

David

 

 

]]> https://docs.microsoft.com/archive/blogs/dc995/developing-applications-using-windows-authorization-manager-white-paper-released Wed, 16 Aug 2006 21:44:00 GMT https://blogs.msdn.microsoft.com/dc995/2006/08/16/developing-applications-using-windows-authorization-manager-white-paper-released/ Check it out!

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetserv/html/AzManApps.asp

 

]]> https://docs.microsoft.com/archive/blogs/dc995/source-code-for-the-authorization-manager-azman-asp-net-role-provider-released Wed, 05 Jul 2006 13:44:00 GMT https://blogs.msdn.microsoft.com/dc995/2006/07/05/source-code-for-the-authorization-manager-azman-asp-net-role-provider-released/

Check out the Source Code for the Authorization Manager (AzMan) ASP.NET  Role Provider

 

https://msdn.microsoft.com/asp.net/downloads/providers/

Under Deep Dive...

 

 https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/asp2prvdr03.asp

 

Differences Between the Published Source Code and the .NET Framework's AuthorizationStoreRoleProvider

The source code for the AuthorizationStoreRoleProvider is being released unchanged. This means you will not be able to compile it in its current state, because it contains calls to internal helper methods. However, you can reference the source code to see exactly how the provider maps role manager calls to AzMan.

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/asp2prvdr01.asp?frame=true

Role Providers

Summary: Describes the design and operation of the various built-in providers that Microsoft ASP.NET 2.0 uses for state management services. (6 printed pages)

Click here to download the entire series in PDF format Microsoft ASP.NET Providers.pdf.

Contents

Microsoft ASP.NET 2.0 Providers: Introduction
Membership Providers
Role Providers
Site Map Providers
Session State Providers
Profile Providers
Web Event Providers
Web Parts Personalization Providers

Click here to download ProviderToolkitSamples.msi.

Find the file AuthStoreRoleProvider.cs.txt

Regards,

David

 

]]> https://docs.microsoft.com/archive/blogs/dc995/how-to-use-adam-principals-in-authorization-manager-azman-for-fine-grain-authorization Sat, 06 May 2006 11:39:00 GMT https://blogs.msdn.microsoft.com/dc995/2006/05/06/how-to-use-adam-principals-in-authorization-manager-azman-for-fine-grain-authorization/ Check out this really cool post from the AzMan Team blog! https://blogs.msdn.com/azman/archive/2006/05/06/591230.aspx 

The ADAM and AzMan teams got together to show how to use ADAM principals with AzMan.  Sudheer, Authorization Manager Team, provides a description and csharp / C# code from that effort. Note: you need to be using Windows 2003 SP 1, the updated Win2k3 Admin Pack for XP or the updated Win2k backport. 

Regards,
David

 

]]> https://docs.microsoft.com/archive/blogs/dc995/random-thoughts-on-optimization-and-choices-with-authorization-manager-windows-2003-sp-1-article Wed, 05 Apr 2006 21:16:00 GMT https://blogs.msdn.microsoft.com/dc995/2006/04/05/random-thoughts-on-optimization-and-choices-with-authorization-manager-windows-2003-sp-1-article/ Another new article by yours truly...

Random Thoughts on Optimization and Choices with Authorization Manager - Windows 2003 SP 1  https://blogs.msdn.com/dc995/articles/569487.aspx
 

]]> https://docs.microsoft.com/archive/blogs/dc995/random-thoughts-on-optimization-and-choices-with-authorization-manager-windows-2003-sp-1 Wed, 05 Apr 2006 20:37:00 GMT https://blogs.msdn.microsoft.com/dc995/2006/04/05/random-thoughts-on-optimization-and-choices-with-authorization-manager-windows-2003-sp-1/ The following is my opinion... and my opinion may change based on the context that the individual items are placed.  With that said... I hope you find them useful.

 

Store Selection: prefer AD to leverage existing investment in availability and performance then ADAM (functional mode, political, organization policies, etc)

 

Authentication: prefer AD to take advantage of multiple client context initialization e.g. token/name/sid.  ADAM is very popular for Internet access however some additional code is required for SID/role population in security client context. Another cool part about the
Win2k3 SP 1 update is that it possible to use dynamic ldap query groups with ADAM. The binding is signed and sealed... so pointing to an ldap store other than ADAM is not supported.  Another thing to note... since the coder is doing the pointing on an attribute of the client context,  it is possible for that coder to point to the wrong DN. Check out ADFS which may use AD or ADAM as the AuthN store for claims based applications and utilize AzMan as the transformation engine between ADFS claims and either AzMan application groups or directly to roles.  There is a small bit of code with an example pending in a future ADFS SDK.

 

Performance: 

• Use AD principal - use initialize client context from token when possible https://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/iazapplication2_initializeclientcontextfromtoken2.asp?frame=true 

reducing the additional (internal) call to populate security context sids.

• Wrap large number of users in AD groups so that the only compare required is against the group Sid.

• Use scopes where applicable. 

• Minimize usage of dynamic query groups when you want to reduce lookup times. 

• Make judicious use of business rules. Keep them short.

• Try to limit Application groups to fewer than 1000 members if possible reducing lookup time. The load time is reduced with a smaller dataset size of SIDs.

• If unable to move domain to Win2k3 functional mode use ADAM and load balance for performance and availability. Check performance counters and network health. Test and tune.  Remember that a server needs to be listed when using ADAM e.g. there is no server-less bind e.g. for ADAM msldap://myserver:50000/CN=azstore;CN=azmanapps;DN=foo;DN=COM vs AD with CN=azstore;CN=azmanapps;DN=foo;DN=COM

• When using AD ensure a healthy directory/infrastructure.  Validate/identify DC that is being utilized for lookups and try to have it relatively close in proximity.

• Utilize Win2k3 SP1 and new interfaces for better performance including store creation/population

• Avoid role bloating - favor scopes.

• Utilize trusted subsystem model for store access as opposed to impersonation model where all end users get some level of access to the authorization store itself. Avoid impersonation model on win2k if possible. There is also a different API

• Note transactions are not supported but multiuser access and administration is when using other than XML store.  XML store will support multiple reads but when using .NET use locks or catch errors on access.  When reading, the whole XML store loads and writing the whole XML writes to disk.  AD and ADAM utilize a lazy load mechanism where gathering data is done as needed. Caching grows to the size of the store for each process with it open.  The largest store that I have personally seen is 15 MB.  I would like to hear about any greater than than.

• Design audit information for clarity per the accesscheck

• For code readability you may choose to enumerations or constants for your operations
• Delegation is possible with AD
• Remember to see the operations that the MMC (AzMan.msc) must be in developer mode otherwise it only shows tasks (which is the level that most admins would look at anyway)  Tasks being a logical grouping of low level operations that make up a role definition.
• Reduce network calls through multiple ops in accesschecks when possible. When using .NET – I recommend wrapping the result of the accesscheck from S_OK which equals 0 to either a Boolean response of True or False or returning an array/list of the same

• Check out existing docs

• https://msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager/ 

• https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/management/athmanwp.mspx

• https://support.microsoft.com

 

Check out the AzMan Team Blog https://blogs.msdn.com/azman !

]]>