The Basics of Claims – Part 4 – SharePoint Authentication Logic is Simplified with Claims

There is logic found inside of any application out there which supports the various features that it offers. However, applications aren’t always able to successfully rely upon the Windows authentication to help it with the process. You may have web based application that store the names and passwords of users. They may need to be reset when lockouts occur or there is a breach in the system. With enterprise facing applications, there is a domain controller in place that Windows will use to authenticate.

There are plenty of challenges that can occur though in spite of the presence of integrated authentication though. Kerberos tickets are able to give you a list of groups and user accounts. What are you going to do though if you have a need to send an email to them through your application? As you can see, that would become complex in nature to achieve even when you are only working within the framework of a single domain.

While Kerberos does have limitations, you can get around them when you program the Active Directory. This is a complex process though so be ready. Your goal should be to have a very efficient LDAP (Lightweight Directory Access Protocol). This way the queries made aren’t going to slow down your directory server.

You will find that with claims based identity you are able eliminate the authentication logic when you are talking about individual applications. What will happen is that there is an application that verifies the user through the claims process. Therefore, claims is a way for your to get rid of authentication logic in terms of your application.

Don’t let the concept of claims based identity intimidate you because it is used all the time and it is everywhere in society. Let’s take the authentication protocol that is in place at the airport as an example. You aren’t able to just go to a gate to board a plane with your photo ID in hand. You have to go through a process that requires you to check in at the right ticket counter location prior to proceeding to the boarding gate. You will be asked for various information at that time including your name and photo ID.

For those passengers with a flight that takes them out of the country, a passport will be required. All of this pertains to adults traveling but not to minors with them. The only thing you will need to provide for children is their names and so that becomes their authentication. The person behind the ticket counter will also make sure there isn’t any problems with the payment that was processed to pay for the flights. Once all that is done boarding passes are issued and then you can head to the gate for your plane.

All of the information you need to get onto the plane is offered on that boarding pass. The agent at the gate will look at your name and they can even see if you are a frequent flyer member. They will also see your flight number and your seating location. There can be additional information too depending on the specific airline you happen to be flying with. Everything on a given boarding pass allows the process to be a smooth one for customers as well as staff.

If you take a closer look at any airport boarding pass, you will also notice that there is a bar code on it. Some of them have a magnetic strip in lieu of it. There is plenty of information encrypted into those areas too. For example the boarding serial number that shows it to be legitimate as there are ways to make fake boarding passes out there.

All of the information on a given boarding pass is a set of claims that the airline has for identifying you. It verifies that you are authorized to be getting onto a given airplane and assigned a particular seat on it. The agents that are at the gate are going to view your boarding pass, they don’t have to ask you for all the same information that you already gave when you first checked in.

Another scenario though is that you may be able to get the validation you need from another source. For example many airlines now make it convenient to get your boarding pass online and then you can bypass the ticket counter when you arrive at the airport. Which method you used to create your boarding pass won’t alter the end result that it allows you to get on your flight as specified. This is because the claims linked to it have been authenticated.

When it comes to software, the claims involved are referred to as the security tokens. Each one is to be signed by a particular issuer that has created it. In a claims based application, the users are authenticated when they are able to present a signed security token that has been validated by a trusted issuer.

When you are talking about an application developer, they have an advantage with this type of system. You see the application won’t need to have a specific type of credential involved from the user. Of course the person in charge of security for your company is going to create policies and rules that will be evaluated by the user. What your application receives is very similar to the boarding pass information I just shared with you.

What all this means is that regardless of the authentication protocol that is used the application is going to get a set of signed claims. These claims will have the pertinent information on them about the user. This information is in a format that is simplistic in nature and the application will be able to use it immediately.

Share

The Active Directory Membership Provider and SharePoint

It is relatively common with a corporate environment to use Active Directory as the method of network user management, for authentication to a variety of applications, one of which is typically SharePoint. With the new version of SharePoint, there is the ActiveDirectoryMembershipProvider, which provides all the features that are exploited through the use of custom as well as the standard SQL provider that is shipped with Microsoft Office SharePoint Server (MOSS). While using the Active Directory membership provider, one can use either the full version of Active Directory or the lighter product Active Directory Application Mode (ADAM), and although the provider is quite similar to the default SQL provider that is shipped with MOSS, it clearly has some distinctions because of the way that it must interact with the directory server. It is important to keep in mind that although AD and ADAM appear to provide the same functionality, ADAM is a much lighter version of AD, and an architect must plan accordingly for the extra features that Active Directory will introduce into an environment. If you domain environment is rather complex, and a large forest with a large amount of trees, it is best to use a test environment when firstly setting up the ActiveDirectoryMembershipProvider, paying particular study and analysis to the domain that you plan on leveraging the provider in before implementing and binding it to your SharePoint environment.

LDAP and The Active Directory Membership Provider

The provider AD provider is also called the LDAP (Lightweight Directory Access Protocol provider because the AD/ADAM provider will in essence communicate with the directory using LDAP commands, this is how the provider is structured. It is quite different from the SQL membership provider in this because it will never return a tangible login token, the provider simply builds the structure by which SharePoint can make LDAP calls to the directory server and marshal back those returns back to SharePoint, there is never any security context that is bound to the actual thread.

Directory Containers

Operationally, the provider works with the directory containers. When examining the Active Directory provider, there is a separation yet common architectural consideration between AD and ADAM at this point since the two technologies are dissimilar, yet alike, in regards to extendibility and manageability. When using the provider against a full blown AD environment, it is important to realize that the provider will point to a singular domain, and within ADAM, the provider needs to be pointed at a single application partition, which is essentially a separate domain. It is however, possible to use the provider within an environment that has multiple domains, however the provider must be instantiated however many domains are going to be bound to the AD provider, i.e. if you have 4 domains you are going to have 4 provider instances.

Global Catalog and Connection Strings

Although the Active Directory provider may seem like a new way to interact with Active Directory at a variety of levels, there are some consideration in terms of what can be read and written when using the provider. Active Directory at its heart use the global catalog to manage all the queries that are done against it, particularly when there is a large domain forest with multiple domains that exist under it, it is the core portion that lets an administrator manage various types of user objects. There are however several assets that exist in the global catalog that are considered read only, and therefore are not good for the provider to interact with, such as modifying user information from the provider when prefixing the connection string with the global catalog conventions. Similar to how the SQL membership provider will work, so does the Active Directory membership provider, in that it also uses the concept of connection strings to know where it should point to. The provider connection strings are quite similar in structure as well:

[xml]

< connectionStrings >

< add name=adconnection connectionString=LDAP://SharePointDomain.dns.name/ >

< /connectionStrings >

[/xml]

The exact connection string will vary however between Active Directory and ADAM, for example, you might find this connection string for a full AD environment:

LDAP://sharepointdc.mysharepoint.com/OU=SharePointOU,DC=mySharePoint,DC=com

Caveat Of Using ADAM

However when using ADAM, since it must be instead have the specific container information for it, it will looks slightly different. This differs from Active Directory because the provider when working with SharePoint can instead just be pointed to the at the domain, in which case the AD provider will use the user containers since it is the most common within an enterprise (this is the default option). This is however configurable, and the exact container that will be used can be set within the configuration in the connection string (similar to pointing the container for ADAM). If you require a more extendable option, one in which there are several containers, it is best that the containers are structured in the a hierarchal environment, in which there are parent containers with children ones. For most operations that the provider will use, this will prove to be an adequate architecture since it will search through the children containers when performing queries. This although may result in a complex container architecture, but is a powerful option to leverage if you must leverage several containers to use with the provider, and typically much easier to set up than a more complex multiple instance situation with the provider. It is however important to realize that certain actions within this type of environment are not legal, and will fail unless you do setup those separate instances. If the users aren’t pre-existing, and you require operations for deleting existing users, this is a poor architecture to use, since these operations will not be successful because these operations cannot transverse through several levels. All users that are created or deleted must exist at a specific location in order for user creation and deletion to be successful. Nesting containers, regardless of methods lost when integrating containers that exist outside the one specifically named, is still a powerful mechanism for the SharePoint architect to use. The methods that are being lost typically will fail because as these types of methods are executed against the directory server, it requires that the user object firstly be acquired, in which case a larger search scope cannot be applied in order to gain access to the user object. It is important to realize the child and parent relationship as well, the search query will allows being at the parent and then crawl down into the child OU’s, unless you explicitly name the child container in the connection string, however this would negate the idea of nested containers since there would be no down crawl into the children OU’s.

With regards to connection strings, they will also vary heavily with ADAM since we are pointing a specific container, as opposed to an entire domain that will be default use the User container, this looks like the below:

LDAP://sharepointadam.mysharepoint.com/OU=OU,O=organization,DC=mysharepoint,DC=com

Security Attributes When Using the Active Directory Membership Provider

There are as well some security attributes that are associated when connecting using the Active Directory provider to whatever SharePoint AD or ADAM instance you are leveraging. This is a very simple attribute, connectionProtection, and luckily, it isn’t very complicated to implement because it is a Boolean value, either you want it on or you don’t. This attribute just provides a method by which there can be a secure connection that exists between your directory server and the Active Directory membership provider, and by default it will take the attribute value of Secure, as opposed to None. It is a best practice to use Secure in all environment besides development environments where production level data wouldn’t risk being exposed. In a production environment it is poor practice to leave the connectionProtection attribute set to None since various operations require that a secure connection be established, however for ADAM sometimes it will use the None attribute because it requires setting up SSL certificates. The last attribute that deserves attention is it is also possible for one to add the username and password that they would like to use when connecting to the directory server, otherwise it will connect through the credentials that are bound to the worker process.

Share