SharePoint Claims Based Authentication Architectures Explained Part 8 Design Principles for Claims Based Applications

It can prove to be difficult to give guidance in the area of designed claims due to the fact that they work independently off of a given application. This next section is going to help answer questions you may have though and to offer a look at some different approaches you may want to consider implementing.

The Fundamentals of a Good Claim

There isn’t always a clear answer when it comes to the design for claims based applications. This is why it is important for you to understand the different variables and the tradeoffs that each one of them can offer you. With these examples though you should get a solid understanding of what types of elements need to be present in order for you to have a good claim.

The email address of the user is one thing to consider. When you have a candidate for a claim in a given system an email address is a good way to identify them. Just about everyone out there has an email for business purposes and it will be required for you to federate identity across realms. With an email name, you will be able to get your system personalized for each user.

There is some personalized data that can be used too. For example a user may have a specific skin or theme that they wish to use for a website. This is also a type of date that is specific for a given application. Choosing a skin or a theme here doesn’t make sense because it isn’t part of the users identity according to the verification process. Therefore this should be managed as a whole rather than individually.

There are users that will have permission to access date in your application. It can make sense to model permissions as claims but you nee to realize that soon you may end up with too many of them within your levels of authorization. A better way to handle such issues is to develop a boundary that will separate the authorization data from claims and that which you can handle another way.

A good example is that you have a cross realm federation that can be a benefit by allowing realms to be authorized for high level roles. The application will map these roles into fine detailed permissions with various tools. A common one used is Windows Authorization Manager. You do need an issuer that is designed to handle this fine detailed permission process though so that you can keep your claims at a higher level.

Here are a couple of questions that you need to ask before you go about attributing a claim:

  • Is the data going to be a core part of what I use for identity?
  • Will the date be used by only one application or several?
  • Will an issuer manage this data for me or should I have it handled directly through my own application?

ADAM (Active Directory In Application Mode) Custom Role Provider

Introduction to the Standard ADAM Role Provider
ADAM (Active Directory on Application Mode) has become increasingly common for companies that want to implement a featherweight directory protocol to use within their SharePoint environment. With ADAM, setting up role based security principles is common because it is an extendable architecture that provides the benefits of Active Directory without the management and implementation overhead, and also allows the concept of binding roles to operations which is a very helpful function since beyond acting as a role and user data store, the ADAM instance can become an engine by which to run an mixed, integrated SharePoint and miscellaneous application environment. The AzMan role provider limits the users that you can integrate with the LDAP pluggable provider to those that resolve to a tangible windows identity (it must be a domain account), which of course is a problem for people that wish to use ADAM only users. With increased support for ADAM in SharePoint 2007, the requirement from customers has become even more prevalent and for some, the lack of role support has become a cause for concern.

The Need for a Role Provider
In other articles in the site (notably here) there have been detailed explanations that go into using the AvtiveDirectoryMembershipProvider in your SharePoint environment and how to do so, and this provider is indeed incredibly central when implementing ADAM within your SharePoint environment for user authorization. However, it is necessary to implement a custom provider that will support the same role type functionality that is available to other providers to those same ADAM users, allowing one to bypass the limitation of only supporting assigning roles to actual domain accounts.

The provider that comes with the default instance of ADAM is AuthorizationStoreRoleProvider, which couples with the functionality that is provided by the Authorization Manager. The actual communication happens with a primary interop (, which is a COM object (discussed shortly) imported from the type library AZROLESLib. The membership functions of ADAM with the latest releases of ADAM is supported, and storing principles without resolving to Windows identities works fine.
Role Provider Functionality
There are various layers of supported functionality that exist in the default role provider that are extended in the custom provider that is available here. Notably, AddUsersToRoles, CreateRole, DeleteRole, FindUsersInRole, GetAllRoles, GetRolesForUser, GetUsersInRole, IsUserInRole, RemoveUsersFromRoles, RoleExists, and other lower level functions like getting application names. Most of the methods that are in the ADAM role provider should resemble other providers that must be built in order to support database transactions of other origins, whether it is Oracle, flat-text, DB2, or Informix, the ADAM role provider will have several characteristics that are the same.

There are some important best concepts that must be considered with the ADAM role provider. The first is to take the concept of application name into consideration, in this case it is done by referencing the ADAM application which will in turn provide the methods that are needed in order to talk back forth between the role provider and the ADAM backend datastore, this is important in order to allow segregation of data points provided by the application name so that multiple vectors can exist. Because multiple applications can exist that are used by a provider, an attribute can be determinably expressed for provider functionality. If in the configuration files an application name is not specified, then the default application name as determined by the .Net framework. This can be extended further when assimilating the concept of ADAM application scopes which allow you to drilldown even further.
Since scopes are a lot less common than scopes, lets see a brief overview on getting an application name.

The first thing that we have to do is initialize a new AuthorizationStore object by calling a new AzAuthorizationStoreClass(). Following, we have to get the values that we require out of the configuration sections (the connection strings that are specified), and then call OpernApplication() out of and return the application name.

Firstly, there is the concept that the provider will have to inherit out of the RoleProvider base class, which derives itself out of the System.Web.Security namespace. Unlike other concepts introduced on the site, such as using Façade patterns (factory patterns that develop a generic interface for providing a certain set of functionality, see here) for transactional provider interaction, the ADAM role provider is slightly more specific, i.e. as opposed to database factory patterns that are abstract the methods introduced are in fact concrete by nature.

Role providers are quite easy to write and to implement, because they are typically just sealed or abstract classes, and the parameters that are massaged are very simplistic, they are role names, and the users that are associated with those role names. There are a couple methods that should always be implemented, and others that although may be considered optionally, are nonetheless very important.

As an example, lets examine the most obvious method, creating roles. This is done by using the CreateRole methods, which will simply create a new role in the backend datastore. There are of course some conditions that must be checked before connecting to the datastore that ADAM provides before you actually create the new role before executing committing actions. The first is to examine illegal character conditions, and the second is that the role name doesn’t firstly exist. Checking whether the name already exists can be achieved by simply iterating through the available roles and then determining whether the roleNames that are being returned match those that are passed in as a parameter:

The second condition to check is whether there are illegal characters that are in the role name. This is done by doing an if statement and using an IndexOf in order to tell whether the passed in character string is indeed in the role name. The only one that is technically illegal with a role provider is actually a comma, however if you have standards that you must implement in order to conform to a role name requirement, you can use the same type of technique.

After the conditions are met, it is time that you can actually add the role that you want.
The methods that are needed as you can see are pretty simple and easy to implement, although this article won’t detail them all, there are some central concepts that should be covered.

Configuration Elements
As with the other providers that are implemented for your SharePoint environment, one of the most important changes that you will make is the configuration elements for the web application. This is accomplished in two different places, the connection strings elements so that the LDAP connection can be made and the role manager section which will specify the provider type, reference to the connection strings settings, and the application name since it will help define scopes for your business applications.
The first of these is to setup the configuration string which will define the connections that are made to the ADAM data store.

< connectionStrings >
LDAP://,DC=sharepointsecurity,DC=com/ >


The second this is to enable the Role Manager, set the default provider to the ADAM role provider, and then set the application name in the configuration elements. The type name is the custom role provider name, in this case ARB.ADAM.RoleProvider.

< roleManager enabled=true defaultProvider=directoryProvider >
< providers >
< clear / >
< add name=ADAMRoleProvider type=ARB.ADAM.RoleProvider connectionStringName= ADAMStoreConnection applicationName=SharePoint/ >