SharePoint Security And Authentication Part 3 – Claims Authentication Design And Services

With SharePoint Server 2010, claims based authentication and classic mode authentication are both supported. Claims based authentication is part of the Microsoft Windows Identity Foundation (WIF). This is a set of .NET classes that allow for claims to be processed with WS Federation authentication. WS-Federation is a type of protocol for authentication that builds on the WS-Security and WS-Trust. It supports a token based authentication structures so that a web application required to offer security tokens can be accessed. With SharePoint Server 2010, you have the chose if you want to use claims based or classic mode authentication each time you create a new web applications. With classic mode authentication you will have the Integrated Windows model that was supported by SharePoint Server 2007. There aren’t any claims changes that are performed so the new claims authentication features can’t be supported. When you choose to use classic mode authentication you will be able to implement all of the method that were supported by SharePoint Server 2007. You are also under this pretense going to be limited to the use of one form of authentication for each of the zones. With claims based authentication for SharePoint Server 2010, you will be able to use authentication for the entire span of Windows based systems. You can also use it across those systems that aren’t Windows based as well. With claims based authentication, you will support the delegation of a user identity between applications. This allows you to implement multiple forms for authentication in a particular zone.

It is important to understand the basic components of claims based authentication. Yeah this has been covered a lot on the site but its critical. A security token is the main component of claims based authentication. This security token consists of sets of identities about a user. This can include their user name, the role they have in the organization, an employee ID that has been assigned, and other variables that an organization uses. The values of these identities are assigned a value that is in a text string. The security tokens are created and also managed by a Security Token Service (STS). Policies are implemented based on the decisions of the organization about how those security tokens can be distributed based on authentication of a user that proves they are authorized.

With a claims based application, WIF is able to create a WS Federation authentication request. WS-Federation is an authentication protocol used to build on what WS-Security and WS-Trust have instilled. WS-Federation supports the overall architecture of this token based authentication. This process allows the web application to require a security token before the authentication process can be completed. Without it, a user will never be able to gain access to the resources. Once the Windows user identity is created it is converted to WindowsIdentity by SharePoint Server 2010. From there it is converted to ClaimsIdentity. The object is then able to use used for the purpose of creating a token.

A Security Token Service takes on the role of responding when requests for authentication are made. The security tokens for identity claims are evaluated based on the user account information that has been stored in an Active Directory Domain Service, arbitrary LDAP Store, or an SQL Database. Each security token has content in it that is determined by the types of requirements for authentication requests that have been determined with the Security Token Service and the SharePoint web application. The claim rules are also the policies that will be used as requirements to be met before a web application can be accessible. There are two function of a Security Token Service. It can serve as a local Identity Provider Security Token Service when they are in the same web application as the SharePoint farm. When they are located in different farms though the function of the Security Token Service is that of Relying Party Security Token Service.

With Identity Provider Security Token Service, the identity providers and the web application have the same farm through SharePoint. They will provide tokens to users that have been authenticated and that are in the same local stores.

With Relying Party Security Token Service, the partner identity provider has a trust relationship with the Identity Providers Security Token Service as well as the web application. These entities can be located in different SharePoint farms. This is a trusted relationship that allows the Relying Party Security Token Service to authorize an external user even if the credentials of that user aren’t locally stored. As long as the Identity Providers Security Token Service of a user is able to issue a valid security token that process will take place without any problems. It is possible for a new token to be issued that is able to validate a web application that may be local to the Relying Party Security Token Service but external to the user.

There are two types of claims based authentication topologies that can take place. One of them is a single farm that requires the use of a Security Token Service that is local. There is also the use of a multiple farm topology that uses both a local Security Token Service and a Relying Party Security Token Service.

Assume an incoming request for authentication that comes from an external user. The credentials are going to be accessible by Security Token Services. The request is then submitted and processed by the local Security Token Service. In order for that to happen, the policy for a given web application must create a token. This is going to be based on the identity of the user and the values of the store. A valid token will be returned to the user and then it can be submitted to the web application once a cookie has been returned to the user.

When a user has credentials that aren’t directly accessible by a local Security Token Service, the web application is going to respond to the authentication request from an redirect to a partner Security Token Service. This request is submitted due to the trust relationship that exists. An Identity Provider Security Token Service is created for the user and then submitted to the local Security Token Service. There it is deciphered for the token and then it is returned to the external user. Then the web application will return a cookie to the user.

In order to successfully complete crawls of content for any web application, it is important to understand how the authentication works for it. The indexing element of the search server is what is referred to as the crawler. Successfully configuring the authentication for web applications ensures that the content in those applications has been crawled. A farm administrator will create a web application that uses all of the default settings. The zone for that default is created through a web application using NTLM. The farm administrator can change the method of authentication for the default zone through any of the SharePoint Server 2010 supported methods. The farm administrator also have the ability to extend any web application several times so that additional zones can be offered. As many as five zones can be offered for any particular web application. These zone are configured through the use of any of the SharePoint Server 2010 authentication methods. The planning zones for a given web application has to be considered in order for the access zones to be displayed in an orderly fashion. This process will occur then an attempt to authenticate is completed. The order is very important so that the crawler is able to get through the zones that are configured. If the crawler can’t gain access through one of the zones, the authentication will fail and then there is going to be content on the web application that isn’t crawled. It is a good idea to have NTLM zoning configured early in the order. It should be before authentication for basic, digest, or Kerberos.

The zones that the crawler will access will occur in this order:

  1. Default zone
  2. Intranet zone
  3. Internet zone
  4. Custom zone
  5. Extranet zone

These are the actions that will be associated with the call out process:

  1. Crawler uses the default zone to attempt authentication. The crawler will always attempt to use the default zone first for any particular web application.
  2. If a zone has been configured for NTLM then the crawler will move on to try to authenticate that in the next phase.
  3. If a zone has been configured for basic, digest, or Kerberos authentication then the crawler may fail and not continue to crawl all of the remaining content within a web application.
  4. If there aren’t more zones in the order the authentication may fail.
  5. The crawler will them attempt to complete the authentication by moving into the next zone in that order. You must create at least one more zone and configure it use NTLM authentication.

Next in this SharePoint security series, the last post in it, we will be talking about how to build the security design, and what SharePoint security best practices should be implemented in particular environments.

Share

The Basics of Claims – Part 5 – The Making of a Good Claim

There is plenty of information that may be stored within security tokens. This can include the name of the user, their email address, the email of their manager, and anything else that you would like to use for identification purposes. It is a good idea to consider claims as being just like the various elements of Active Directory and that you will have minimal control over them. It can be hard to centralize too much information when it comes to users or to issue claims with that type of information for applications.

There are many different types of claims out there that you can issue. You will need to discuss extending the Active Directory set up with your IT department. They will likely only do so if there is a justifiable reason to do so. Often, they already have what is necessary in place so they won’t be making changes to it. You don’t want to have centralized data that is specific to only one particular application though.

What you will find is that applications relying upon claims are able to benefit from a table that stores information about users on it. This is where the application specific user information will be. The other applications out there really aren’t even going to care about this at all. This is the data that you have authority for with a given application. That is the single source for the data to be stored. What is important is that there is someone in place to keep it all current for you.

You can also use such a table to cache data that isn’t authoritive in nature. You will get this information from claims. You may want to cache an email claim for every user so that you are able to send out notification emails without the user having to log in first. You want your cached claims to be in a read only format. You also want to make sure they are refreshed each time a sure visits that application.

You don’t need much to make claims good as a little bit of it will go a very long way. You need a good claim to go hand and hand with an issuer that is able to provide you with user information, to make the authorizations, and to customize the applications just the way you want them.

Once the user has been authenticated, the issuer will create a claim about them and issue a security token. ADFS has roles in place that allow the LDAP materials from the user record that is in the Active Directory. There can also be rules in the SQL statements so that you will be able to access user data. You can also add other stores which is a good idea as many companies out there have an identify that is fragmented in some way. With ADFS though it is hidden so the claims based application won’t be broken if you need to move the data around. The applications aren’t tied tightly to identity which is a huge benefit of claims based identity.

With claims based applications you can decide if you would like to make the users anonymous or not. Since there isn’t an application directly authenticating the users this is possible. This can be a feature you decide to use but you can’t make any claims that will personally reflect on a user. Some issuers out there encourage the idea of private user identification. That way an anonymous identifier that is unique in nature can be used with claims based identity.

Share