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.

Comments

• Anonymous
  March 08, 2012
  What is the current situation? Is there already an authorization plugin available?
• Anonymous
  October 01, 2012
  Yes -- it would be nice to get an update!  We are hearing from our systems people that they are concerned that AzMan is being deprecated, but we are not hearing what the replacement is.
• Anonymous
  November 07, 2012
  I am desperately looking for something that works wit the new .NET 4.5 WIF classes to perform the role AzMan plays. I cannot believe there is no implementation available. Some information on the future of AzMan and how it relates to WIF would be great.
• Anonymous
  February 02, 2013
  Can I use AzMan from ClaimsAuthorizationManager for ASP.NET MVC, WCF, REST (Web API, OData)?
• Anonymous
  June 17, 2015
  I do not think it's professional for the Identity Team to remain silent after being asked valid questions about the implementation of WIF or Claims-Based security. There is a lack of documentation on how to implement this technology and it seems like the Identity Team are the only ones that know how to. There are different scenarios people enforce security, using old models, it would be nice if these were addressed on the new Claims-Based Approach