SharePoint Federated Identity Process – Part 4 – The Benefits and Limitations of SharePoint Identity Federation

You will find that the federated identity has a very flexible structure to it. With that in mind, Adam Buenz’s Software House is able to add customers when they have a trust relationship in place by the issuer and they create claims mapping. This is all very simple behind the scenes action due to the process of such mapping being a very simple process. However, it is also important to realize here that the actual software component order application didn’t change at all. When you create a federation there is only some minor changes to that overall structure that need to be taken care of.

With the claims of ARB Security Solutions the ability to read the name of the business and the name of the employees is there. There won’t be any mix ups when it comes to finding out who accessed the application from Adam Buenz’s Software House and who accessed it from ARB Security Solutions. As a result there is less upkeep involved with federated identity. The accounts don’t need to be copied and maintained even though there are many security realms associated with them.

However, there are some limitations in place to be aware of. First, the way in which the claims mapping works has to be evaluated. Anyone that is with ARB Security Solutions is able to track software component orders due to the way in which the requests are set up with the type role and the value of software component order tracker in place. What you should do though is limit exactly who in the business will have access. That is what we will take a closer look at. 

It is vital that you are able to set up trust relationships. In this scenario the two entities are using ADFS 2.0 for the issuer of their security tokens. A public key certificate needs to be in place. This will be in a file that the administrators from ARB Security Solutions will send to Adam Buenz’s Software House. It is as easy as attaching it to an email and sending.

The administrators for ARB Security Solutions will configure ADFS so that they requests from the Adam Buenz’s Software House issuer will be accepted. All that needs to be done for this to occur is to select TBD menu in the ADFS. The Adam Buenz’s Software House administration will install the certificate on the ADFS host. This allows the federation to work with both issuers.


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.


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.