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

SharePoint Security And Authentication Part 1 – Understanding Authentication In SharePoint 2010

There are numerous authentication methods that are supported by SharePoint Server 2010. Through authentication the identity of a user can be validated. Once that occurs the process of authorization will also determine which sites, what types of content, and which of the features available a given user has authority to access. SharePoint Server 2010 can be considered a type of distributed application. There are three tiers that it is divided into which are all important to consider when determining your authentication strategy:

  • Application server
  • Back end database
  • Front end web server

Each of these tiers offers a sub-system and corresponding authentication. A user has to be authorized before they can go from one tier to the next. The provider has control over what levels of access each user has. Those providers offer various software elements that are used to support a specific method of authentication. With SharePoint 2010 you can use a classic mode of authentication or a claims based method. If you are upgrading from Microsoft Office SharePoint Server 2007 Microsoft documentation will recommended you use the classic mode, personally I think it's advisable to just go claims since you can use the identity generation service to generate Windows identities. If you plan to use a forms based authentication or one that is SAML token based you should use the claims based method. This is because the classic mode authentication will only support Windows authentication.

There are several methods of authentication that can be supported by SharePoint Server 2010. As you explore the basics of them you can decide what will work best for your organization. There are three:

Windows

This is the standard method of authentication. There are many methods that fall into this particular category. They include:

  • Anonymous This allows users to find and access resources from public areas of websites. They don’t have to provide any credentials for authentication to do so.
  • Basic This requires a user to have account credentials that have been assigned ala Windows. There is a web browser that is enabled to provide such credentials when someone makes a request. The credentials of users aren’t encrypted but sent across the network as clear-text. Therefore it isn’t recommended for the use of basic authentication to be used on any connection that isn’t secure. Always use SSL encrypting for additional security.
  • Digest This type of authentication is very similar in function to basic authentication. However, it offers a much higher level of security with it. The credentials are encrypted as they are sent across a network. The username and password can’t be deciphered along the way. Valid credentials must be given by a user that belong to the secret password string.
  • Certificates This offers an exchange of the public key certifications. The use of SSL encryption is used. These certificates are issued by a Certificate Authority. They have to fit the Public Key Infrastructure. This can be done by selecting Windows authentication in the Central Administration area. Once SSL is enabled then the configured certification can be obtained from Certificate Authority.
  • NTLM This is a requirement for any network that receives requests for authentication from client computers which don’t support Kerberos authentication. NTLM is secure and it allows for credentials of users to be encrypted before they are transmitted. Windows NT Server, Windows 2003 Server WorkGroup, and Active Directory use NTLM authentication. It may be the default and need to be disabled if you don’t want to use it.
  • Negotiate With negotiate authentication for either NTLM or Kerberos, they client has to choose one of them. The default is Kerberos. The client application has to provide a Service Principal Name and a User Principal Name for the account. When such information can’t be offered then NTLM has to be used for authentication.

Forms Based

This type of authentication offers support for management systems that need to make identifications. They aren’t based on Windows because they make it possible to work with identity management systems. These use the MembershipProvider interface. This includes:

  • Custom membership providers
  • Lightweight Directory Access Protocol
  • SQL Database

This based on ASP.NET as well as role provider authentication. With SharePoint 2010 it is only able to be used when claims based authentication is used. Forms Based Authentication can be used to be able to authenticate other user accounts too when connected to Microsoft SQL Server database. You need to register the membership provider in the Web.config file in order to use this type of authentication.

SAML Token Based

This type of authentication is claims based. It is created to support a Windows Identity Foundation. This is a set of .NET framework entities used for the implementation of claims based identity. They include:

  • 3rd Party identity providers
  • Active Directory Federation Services 2.0
  • Windows Live ID

Next, we are going to be talking about user management in this SharePoint security series.

Share

The Basics of Claims – Part 6 – Setting up Claims Based Identity

There are some things you will need to do in order to get claims based systems in place. When you follow these steps you will be able to understand more about the overall foundation that is in place.

Adding logic to the applications in order to support the claims is necessary. You will need this to be able to validate the incoming security token and the claims that are inside of it. Through the WIF (Windows Identity Foundation) you will get a common program where they can be verified. You need to make sure that the WIF and the ASP.NET applications are referenced separately.

Next you need to decide if you will built an issuer or use one that is already in place. It is easier to use the ADFS v2 in order to have an issuer for your tokens. Most of the time it is going to be too complicated to create one unless you have an employee with such experience. There are many types of 3rd party software out there that you can use to build your own though if you really want to. These are skills much higher than the basics we are going to cover in this material though.

As you develop applications you will be able to use a stub issuer. This is going to return the claims you need. WIF also supplies a local issuer that is available for prototypes and for the development of the Visual Studio.

Now you are ready to configure the application to the trust of the issuer you selected. Any application out there will trust the issuers of it to correctly identify and authenticate the users before claims can be attached based on the identities in place. It is important to realize this is a one way street the application trusts the issuer but the issuer doesn’t trust the application.

There is plenty of room for variables and creativity when you are talking about claims. Some of them though are more common due to the needs out there. For example they will ask for a person’s name, email address, and even groups they belong to. An issuer can be out there for different claims so the application will need to know what claims are offered.

There are plenty of questions that have to be answered, and you will want to discuss them with an issuer before committing. For example there is the XML document that the issuer has to provide with an application. This has a copy of the issuer certificates so that the right public key can be used to verify tokens as they come in. There is also a listing of the claims that an issuer offers, the URL where tokens are asked for, and many technical details that help with the actual formatting of the token.

There is a wizard program in the WIF that allows the identity of the application to be configured based on all of this data. Once you provide the URL to the wizard for the issuer that you will be using it is going to download all of it and configure the application for you. Then you are ready to configure the issuer so that it knows all about the application.

In order for that to happen you are going to need to provide some basic information. They will want to know what the URI is that identifies the application. They will need to know if all of your applications require claims or not. Do you want the tokens to be encrypted? If the answer is yes, they need to know what key to use. Providing information about the URL for the application so that it can receive tokens is also necessary.

Every application is different so there is a reason why they don’t all need the same claims. There can be an application where the role requires the first and last name of the user. Then there can be another claim where the email address is required. Make sure that any application doesn’t end up getting more information about a user than it really needs. You  need to make sure you are well within the realm of all privacy laws out there.

You will likely be interested in build a claims based application that has a level of security in place. This is why you will need the SSL for the issuer as well as for the application. This is going to serve to protect the information in the token from anyone that may be snooping around. There are applications that require higher levels of security so they can be encrypted to provide it. There will be a certificate and a key needed to that the token can be issued for such an application.

It is the use of the Metadata that allows the information to be shared so easily. There is a tool in the WIF called FedUtil.exe that will generate this for you within an application. There is no need to have to configure any of the setting manually.

Share