SharePoint Federated Identity Process – Part 3 – Exploring the SharePoint Federated Identity Solution

There is a solution here, and that is for both businesses to be able to log into the software component order system. The manager of ARB Security Solutions is able to get the information he needs without thinking about what is going on behind the scenes to make that possible. He won’t need anything special in order to gain that access.

There are several steps that have to be followed to successfully offer access to a user that is in another security domain:

  • The client from ARB Security Solutions trust domain has to send a request to the software component order system application that is within the Adam Buenz’s Software House trust domain.
  • The application is redirecting the client to an issuer that is within the Adam Buenz’s Software House trust domain. However, the issuer won’t need to have any knowledge of who this issuer is to do so.
  • The Adam Buenz’s Software House issuer then redirects the client to an issuer in the ARB Security Solutions trust domain. There must be a trust relationship in place for this to occur successfully.
  • The ARB Security Solutions issuer is going to verify that the identity of the user is legitimate. Then it will send a token to the Adam Buenz’s Software House issuer.
  • The token will be used to create another token that a user from ARB Security Solutions is able to use for the software component order system. As this token is sent to the application, some of the claims will be removed and others can be added if necessary in order for the software component order application to work properly.
  • The application for the software component order tracking system will extract the claims of the client from the security token. Once everything has been authenticated then the authorization will be completed.

The issuer from Adam Buenz’s Software House will be the mediator between the application and the external user. The FP in place has a couple of responsibilities to cover. They have to develop a trust relationship with the ARB Security Solutions issuer. That is the only way it will be able to accept and understand the claims sent from ARB Security Solutions.

The FP must translate ARB Security Solutions claims into something that the software component order system can easily understand. The application is only going to accept claims from Adam Buenz’s Software House so there has to be an assignment of permission in place. Since the claims for ARB Security Solutions aren’t issued from Adam Buenz’s Software House there aren’t any roles here. The ARB Security Solutions claims have to establish the name of the company as well as the name of the employee. Transforming rules are used here to get one claim accepted by another. This is frequently referred to as claims mapping.

There is a claims rule language found in the ADFS so that you are able to successfully define the behavior of identity claims. These rules allow a set of conditions to be true so that you are actually able to issue claims. Right now we won’t be using the name of the employee but we will when we get to talking about the audit features.

When the manager of ARB Security Solutions connects to the software component order system they will have claims sent to the Adam Buenz’s Software House issuer who is also the federation provider. This will then allow them to be transformed into a new set that is going to be easily identified by the Adam Buenz’s Software House claims.

The solution here also involves a home realm discovery being put into place. The software component order application has to know which issuer out there is in use. That way they can properly direct users for authentication. If a manger at ARB Security Solutions opens a browser then they can be authenticated through the information in that. Therefore they don’t have to say which company they are with.

The software component order application will be able to solve the situation by allowing the users to access the web application . There is a query string found in the link. The web application will look for that during the request being processed. The value of the URI for the partner federation server will be easily identified.

Share

SharePoint Claims Based Authentication Architectures Explained Part 3 SharePoint As A Browser Based Application

WIF, short for Microsoft Windows Identity Foundation, is a set of .net frameworks that allow for the creation of claimed aware applications. It gives the user the logic that is needed in order to successfully complete any WS-Federation requests. This is the protocol that builds onto others to offer the trust and security. That is why you are allowed to request a security token when you are using an application that is browser based.

With such a scenario, it appears that the claims in WIF are similar to authentication. When a user is going to sign in, the WIF redirects them to the logon page. Once the user has been authenticated then they will be taken back to the application automatically. You may see a page called Login.aspx but that could be nothing more than an empty page. This is there for those users that need to use a smart card for authentication.

All issuers will be configured to use a method that is natural and that is secure for them to sign in. A simple username and password is usually good enough. However, there are ways for Windows to cover the needs of employers that want a more secure method to be in place. Here are some examples to make that process easily understood.

wa = wsingin 1.0 wa is for action and it will tell you if you are logging in with the wisignin1.0 or if you are logging off with wsingout1.0.

wtreatlm = http://sharepointsecurity.com/SecureCenter/ – wtreatlm is for target realm. There is a Uniform Resource Indicator that is able to identify this application. The URI is used to identify the application that the user has logged into. It also allows other tasks to be done that are associated with the claims for the application as well as replying to addresses.

Once the issuer has authenticated who the user is, it gathers those claims that are necessary for the application with the wtrealm identifying what the target application is. All of this is offered with the security token and there is a privacy key. The application can encrypt the tokens too and then the public key ahs to be used to authenticate them.

The issuer will be told which application they are using so that the claims issued will only be for that particular application to operate. The issuer will ask the browser to take them back to the application. This will send the token to that application for the claims to be processed. After this is done, the user will have access to that given application.

Some of this process may sound familiar to you. This is due to the fact that the forms authentication uses a very similar technique inside of the return URL parameter. This is done when the issuer returns to the HTML page of the browser. This creates the

with the encoded tokens inside of it.

The action of the form is going to submit the toke to the URL that is configured for that application. The user won’t see this form because the issuer has JavaScript in place to post it. Should those scripts be disabled though the user will have to click a button in order to be able to post the response to the server.

For the user there is a Windows authentication in place. The user will click on the link in the application and then the browser will be redirected in a matter of seconds right back to the application. The user will login at that point. Should the issuer require more information from the user such as a username and password or the use of a smartcard it will be done at that time. From the users point of view this type of logon process is always the same no matter what they are accessing and that is what they are after.

Share

SharePoint Claims Based Authentication Architectures Explained Part 2 Claims Architecture Priming

You can use one of many different types of approaches in order to create a claims based application. Both Web applications and SOAP Web Services can accomplish the same thing but they take different approaches for making it happen. Yet the overall structure that is there is the same as it’s the overall goal. The purpose is to create claims that can communicate with each other and that are secure.

We are going to take a close look at how you can evaluate the different types of architecture that can be used. Taking variables into consideration including different perspectives, the experience of the user, opportunities for optimizing, the performance of the different applications, and even how the claims get passed from the application to the issuer all need to be closely looked at. Only then will you see the entire picture of what is offered. I will also give you some advice about how to create your claims and how to know your users.

The overall purpose of the different architectures is to allow for either an active for passive type of federation to be implemented. With an active federation you will have the WS-Trust and WS-Federation Active Requestor Profile in place. They help to describe the way in which the communication between the clients and the services go about requesting a token from the issuer. It also covers how that token is sent for authorization.

With passive federation, the WS-Federation Passive Requestor Profile describes the same type of communication flow between the web application and the browser. In order for tokens to be requested and authorized the web browser has to redirect those requests.

Share