So last week we briefly touched on the characteristics of a good IdM solution or at least an environment that was IdM hygienic. Some of those characteristics included the following:
- View, create, modify, and delete users
- Change passwords
- Add or delete a user in a security group
- Approve or reject requests
- Delegate all permissions
This week I will talk a little about AuthN and AuthZ from a SharePoint perspective (actually everything I talk about in my blogs is from a SharePoint perspective–very myopic, perhaps).
Authentication
Authentication is the concept of: “I am who I say I am” and I prove it with something that only I would have or something that only I would know. In SharePoint, typically, getting access to it means that you must provide your username and password combination; a combination that only you should know. Authentication is a multiutilized word in SharePoint; Forms-Based Authentication, Claims-based Authentication, Classic-mode (NTLM)Authentication, and even Kerberos Authentication. Let’s give a primer on each.
Kerberos Authentication
Kerberos is a protocol as much as it is a method for authentication. I won’t go into the history of the protocol here, but from a SharePoint perspective, again, Kerberos is the system that grants tickets to clients, at their request, for access to services. The name comes from the three-headed dog that guarded the gates of Hades. The three heads are represented by a) The Ticket-Granting-Service (TGS); b) The Authentication Service (AS); and c) The Key Distribution Center (KDC). If the client proves to the KDC that they are who they say they are and the client is correctly configured with a Service Principal Name (SPN), the AS will issue a ticket-granting ticket (TGT) using the TGS and then uses the ticket to access resources. In the SharePoint world, Kerberos is the preferred authentication scheme but is more restictive in that a) you *must* use port 80 or 443 if you want the crawler service to crawl your content and b) You must use Service Principal Names (SPN) for the web applications which consume content on the same server where the content resides.
NTLM Authentication
NTLM (Windows NT LANManager) is the default authentication mode for Windows applications. Again, without a history lesson– NTLM is a protocol that encrypts usernames and passwords before transmitting them over the network. Most people are familiar with the common window or screen that pops up when you try to get access to either a web site or some other resource and it asks you for your username and password. This is called a “Challenge/Response” dialog. What happens next is that you type in your username and password and click ‘OK’ and the machine you are on performs a highly complex mathematical algorithm on your credentials. The result of that calculation is what is sent back to the authenticating provider (in the case of SharePoint, it is typically the Domain Controller). The authenticating provider then decrypts the calculation result using the same complex mathematical algorithm and checks to see if the result gives the correct password. If the password is correct, then the user is authenticated and given access to resources.
Forms-based Authentication
Forms based Authentication (FBA) is an identity management system that uses role and membership providers to authenticate users. These role and membership providers can be SQL Server and ASP.NET or something entirely custom built. FBA allows a user to authenticate themself based on validation of credential input from a logon form. FBA can be tricky to set up in SharePoint; for instance, if you want to authenticate users against an identity management system that is not Active Directory or an identity management system that is not the local system, you must perform make changes to the Web.Config file(s) in SharePoint.
Claims Based Authentication
Otherwise known as SAML-token based authentication, Claims based authentication is the notion that a token that is made up of assertions (called ‘Claims’) is used to determine an entity’s identity. There are three major components in the Claims based Authentication: The Identity Provider (IdP), the Relying Party (RP), and the Security Token Service (STS). In Claims based Authentication (Claims), the token is constructed by a service called the Security Token Service (STS). The Relying Party(RP) relies upon the IdP to validate the credentials that have been presented to it. The RP is typically the keeper of the resource to which the entity wants access and the IdP is typically the keeper of the STS which generates the token based upon the assertions (claims) the entity makes about itself. Identity Providers come in many flavors; for SharePoint the IdP most used is Active Directory. There are other IdPs, such as ADAM or ADFS. The difference between Active Directory and ADFS would be that ADFS can issue SAML tokens where AD cannot. In a SharePoint Claims scenario, a token issuer (read: STS) would need to be able to issue SAML 1.x compliant tokens.
A Primer on How Claims works
The benefits to claims-based identity scenarios is that the application can determine which claims are required and which providers to trust. For example, Facebook may “claim” my name as Slick Rick; however, the Active Directory may assert my name is Rick Taylor. In claims-based identity scenarios we decide which provider is authoritative and handle the request based on the trusted provider or attribute store.
Claims-based identity support enables SharePoint to provide new capabilities, such as, the capability to manage multiple authentication methods within a single namespace. Enabling automatic and secure identity delegation within SharePoint is a key benefit to a number of scenarios, the most common is code. In many cases, code wants to know who you are and subsequently authenticate you to perform some action, Search is a good example. With Search a user executes a query – Search needs to understand who this person is and what results should be returned to that user based on who they are. In addition to retrieving the identity we need to be able to pass that identity across all of the machines involved with the request to return the correct result set.
Seamless integration with external systems ensures the user identity is passed onto all machines and enables SharePoint to access information outside and bring it in, Web Services, etc.
AuthN/AuthZ isn’t all there is
SharePoint can use any of the authentication methods used above in most scenarios. Authentication (AuthN) is still, though, one part of a IdM solution. Certain methods are better than others in certain scenarios and a complete evaluation of the business requirments are needed to determine the AuthN method that is best in the needed scenario. It still does not touch on AuthZ. Just because an entity is verified that they are, in fact, who they say they are–doesn’t mean that they are *authorized* to perform the action they are requesting. In SharePoint, access to Web sites, lists, folders, and list items is controlled through two methods: either role-based membership where users are assigned to roles that authorize their access to objects or access control lists on the resources themselves to which users are given access. Good IdM practice is to use Role Based Access (RBAC), which can cause some headache if not managed properly. It is imperative that a Security Policy be created for access to resources within SharePoint. Without a Security Policy in force enforcing uniform security throughout all site collections will become a manual chore and fraught with error and inconsistency.
In the last part, I tie this all together giving a scenario that implements these principles and gives some best practices at the end.
Was part 3 get posted under a different heading? Searching for “SharePoint and Identity Management” only finds parts 1 and 2.