SharePoint Security And Authentication Part 4 Choosing The Right Authentication Strategy

When Designing authentications strategies for SharePoint 2010, there are guidelines to be aware of with the process for authentication with SharePoint Server 2010. So let's just get down to it. The authentication process is configured through the web application. A server farm may be configured to host sites for many organizations. However, the authentication is configured on an individual level for each of the organizations. It is possible for web applications in SharePoint Server 2010 to be configured with up to five different methods being used. Authentication for internal employees can be completed through one of the standard Windows methods. When a partner organization is involved, their employees can be authenticated with the identity management system that is in place for that particular organization. In order to be able to configure a web application so that it can be accessed by at least two systems of authentication, the additional zones must be configured in the web application. Each of the zones is a representation of a different path for accessing the same application. Typically when there is a partner application, the employees of a partner company are going to gain access to the application through the internet. Internal employees will be able to do so through intranet.  The zone type is a category for naming purposes but it won’t affect the overall configuration of a zone. Once you have successfully extended the web application, you can move on to configuring a new method of authentication for that zone. The default zone that will be in place should only be used by the internal employees. Partner access can be used by configuring the internet zone for forms based authentication.

If you are planning to implement more than one method of authentication for a web application, you will need to plan how to create those zones. There is some best practices to follow. The default zone can be use to implement secure settings for authentication. If a request isn’t able to be associated with a given zone then the settings and security policies of the default zone will apply. The default zone is one that is going to be created when you first initialized the web application. The secure authentication settings are to be used by end user access. Therefore, end users are the most likely to be the ones accessing the default zone. Use the least number of zones that are required by any given applications. Each of the zones will be associated with a new IIS site and domain. They will be used when a user is accessing that web application. You should only add new points of access when they are required. In order for content from the web application to be included in search results you need to make sure there is at least one zone configured with NTLM authentication. This requirement is going to result in the crawl content being indexed. Only create a dedicated zone for that indexing if it is necessary.

There are some methods of authentication that you need to consider when you are planning which of them you will use. Ensure that the methods of authentication are compatible with the browsers that your users will be accessing, understand the methods use for your user accounts to be managed, understand how credentials of users and identity are cached in SharePoint Server 2010, evaluate the pros and cons of each method of authentication available, and evaluate the security of the web applications to be used in SharePoint Server 2010.

Security should be a huge factor that you consider when you are looking at authentication methods for your applications. There are some common security environments for you to evaluate. External anonymous implementations allow for some access without authentication occurring. However, the permission is a read only basis. There isn’t the ability to modify. Authentication can be used to allow access to specific materials. External secure collaboration requires configuring a separate zone for each partner organization that will be connecting to the site. Once a user is no longer employed they won’t be able to continue accessing the application. Intranet implementations are used to protect the credentials of users from being in plain sight.

There are some significant advantages to using certain authentication methods. However, there are also some tradeoffs that occur as well. Exploring both sides of this issue will help you to determine which ones are best for your organization. The advantages of claims include the implementation being a collection of materials for the security token to determine if the user has permission to access a network. These types of materials can include a user name, password, role, or employee ID. All of which can determine the authorization as well as the level of permission.

The tradeoff is that the configuration to manage it all takes a great deal of planning and training. It can be a complex process that a person needs time to fully understand. Windows allows for the authentication of existing Active Directory Accounts to be used. This makes managing any given user simple to take care of. There is no need to write custom code either. Active Directory groups can be beneficial when you complete the configuration in SharePoint Server 2010. The trade off is that not all of the IIS authentication protocols offered are supported by the various web browsers. Therefore you will have to make sure those browsers users are going to use are going to be compatible with it. With forms based authentication, the environment doesn’t use AD DS or Windows accounts. It is possible to have more than one authentication method in place that can help with Identity Management Systems for partner applications to be completed. Authentication users come from the internet. It is possible to customize the authentication process to based on specific criteria. The trade off is that this also requires the web.config file to be customized. It can also be risky if the SSL is in place for an additional layer of security.

Share

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 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