Industry Standards for SharePoint Claims Based Authentication Cheat Sheet

Here is some quick reference material when reading through the claims stuff on the site to help with some of the terminology.

SAML Security Assertion Markup Language

The SAML is an XML based standard and it allows for the exchanges between authorizing and authenticating data that is sent from an issuer to an application. There are several functions of the SAML but the main one is to offer a way for the web browser to be used with a one time sign on process. This is acceptable because the SAML sees that the user has an identity in place and it can be authenticated.

Yet the SAML won’t be able to specifically tell you how to go about implementing these types of services. It really isn’t concerned at all about how the authentication process is implemented. Of course that isn’t the case when you are talking about the individual applications involved. Any application is going to rely on the issuer to successfully identify who the user is.

Once the user requests it, the SAML will apply the policies and rules that are in place. A decision will be made once everything has been assessed.


The purpose of the WS-Federation is to extend the WS-Trust so that the structure of the identity can be created at the core. It is also there to help separate the trust from the security for the tokens. This means that a given service model can be offered to provide security to the protocol address for the web applications and web services regardless of the types of trust relationships you are talking about.

These features are offered for direct use to the clients of SOAP and web services. The WS-Federation is where the syntax for the WS-Trust protocol and the WS-Federation extensions take place in the browser use environment.

There is also the WS-Federation Passive Requestor Profile that is a web based service that works directly with the WS Federation. The details of it show how applications are able to make requests. This includes the use of web browsers which are often referred to as passive due to the way in which they go about making such a request.


WS-Security offers a method of communication so that the security can be successfully put into motion. It was originally designed through the joint efforts of VeriSign, IBM, and Microsoft. Today there is a committee called the Oasis Open that oversees it. This protocol is very important as it helps to get the rules followed for the confidentiality to be enforced. This includes the use of the SAML, X 509, and Kerberos.

This also is attached to signatures so that they can be encrypted with headers that are SOAP messages. To attach security tokens and certifications to messages the WS-Security has to be in place. It works in all of the layers of the application too so that there is security in place from start to finish for each of them.


The WS-Trust is actually an extension of the WS-Security. However, the specific areas that it covers include the issuing, renewing, and then validation process of the tokens for security. It also allows for the various trust relationships to be securely exchanged through messaging. Using the WS-Trust, applications are able to secure that effective communication is in place.


SharePoint Claims Based Authentication Architectures Explained Part 4 Claims Authentication Important Steps

Should a user not be authenticated, the browser is going to request a token from the issuer known as the ADFS where the query is taken to get the right information and a signed token for the browser. Once the POST has been given for the application the WIF takes control. The application has already been configured for this. The FAM will take the authenticate request and validate it at several points. This includes checking to see if there are any restrictions for a given audience that is requesting the token. The expiration date will also be validated.

When there is audience restriction in place, the Audience URI will be in place. This is what determines if the tokens have a claim that will be sent. The FAM uses the public key to make sure the token was signed by the trusted issuer. If it feels anything was modified in transit then access won’t be allowed. The claims in the token will issue a cookie at the start of the logon session. This is the same thing that would happen if you were to used forms authentication.

The process isn’t repeated again until the user is ready to sign off. When they do so, that cookie will be destroyed. This can also happen if there is a time limit on a session and that time has been reached. After the FAM creates the session token, the cookies are then compressed and encrypted for the coding. The cookies are offered in chunks so that there isn’t any problem encountered with size.

There are some other steps too but they will run with the SSL (Secure Sockets Layer). This ensures that someone can’t be looking at what is taking place and then steal the token and use that information to gain access to what only a legitimate user would be able to. The key is to get the best optimized performance possible through the process.

The logon session cookie can be used to cache for the client so that reduces the number of times a round trip is required by the issuer. The issuer also has its own cookie so that they can be logged in while the issuer has to go back and access other applications. This means when someone visits a second application they will be taken right back to that same issuer. When the issuer sees this they will know that it has all been authenticated. This is how it is user friendly with one single sign on for the browser based application.

You won’t even need a browser though when you use a web service. You will use a client application that has logic for handling the claims based identity process. There are two different protocols that are used for this. The WS-Trust helps to get a security token from an issuer. The WS-Security allows for the token to pass to the claims based web service.

The same procedure for the SOAP based web service applies here. Using the Microsoft Visual Studio development system or a command line tool, you can download the WSDL (Web Service Definition Language). This document supplies the various details for the binding, the contract, and the service address. This tool also creates a proxy for updating your application configuration file using the information that is in the WSDL document.

This can be done with a claims based service and the WSDL document as long as the WS-Policy has the details it needs about an issuer so that the service trusts can be verified. The proxy will know it needs to get a security token from the issuer before it is able to request anything from the service. Since the information is stored in the configuration file on the client application, the proxy is able to get the token before it talks to the service. This is firmer than with the browser process because the browser first has to be redirected by the issuer.

The steps involved for a smart client are very similar to those that are used for a browser based application. The smart client is able to make a round trip to the issuer with the WS-Trust to get a security token. The orders web service is configure with the WS Federation Http Binding. This binding offers a web service policy that allows the client to attach a SAML token to the security header. This will successfully create the web service processing.

For this to work, the client will need to call the issuer with credentials including a username and password. This is required to get a SAML token then the client can call the web service with the token attached to the security header. The WS-Trust request includes a field called Applies To so the smart client can attach. This is very similar to the wtrealm query used for the web browser.

Once the issuer has verified the user the application can be accessed. The issuer will send back the response including a security token that is signed. It will be encrypted with the public key for the web service. The token includes a proof key. This is a key that is randomly generated by the issuer. It is included as part of the RSTR and the client will also have a copy of it.

It is the clients responsibility to send the token to the web service that is in the security header of the SOAP envelope. The client has to sign the SOAP headers with the proof key. The additional level of encryption helps to ensure that the web service was definitely the one who was issued the token. It is common for a start up session using the WS-Secure Conversation to be used. The client will cache the RSTR for a day and then they need to connect to it again.