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 Federated Identity Process – Part 2 – Federated Identity Environment Requirements

In order for federated identity to happen, we have to first identify the goals. In this scenario it is for the federated identity to be in place for the application Adam Buenz’s Software House offers and that ARB Security Solutions needs access to. There is one secure domain that will accept an identity from either of these two domains. No one will need any additional credentials in order to be able to access it. The Adam Buenz’s Software House issuer trusts the claims that come from them but also those that come from ARB Security Solutions employees.

There are some requirements that have to be satisfied. First, Adam Buenz’s Software House has to control access of the software component order pages. Otherwise they wouldn’t be able to allow ARB Security Solutions employees access to them. The concept of home realm discovery is involved here as that allows Adam Buenz’s Software House to find out which issuer has the credentials to do so. ARB Security Solutions will also need to make a decision about what employees are going to be able to access that software component order system.

There are few things here that need to be assumed for this scenario too. First, we assume that ARB Security Solutions has an issuer using the WS-Federation. This is important because it defines how businesses are able to share identities without breaking the boundaries of security that may be in place within their own systems.

The software component order system in use will have roles in place so that access can be controlled. This is done by having a claim in place for the type of role someone needs. There is also a value in place and that needs to be an software component order tracker. There will need to be legal documentation in place too between these two businesses so that their needs and rights are well protected. Only then can the federation legally be formed.

Share

SharePoint Claims Based Authentication Architectures Explained Part 9 Specifying the Identity of a Given User

It is vital to be able to uniquely identity each user. This can prove to be very tricky at times because people don’t have that automatically as a part of them. A large portion of people are also very skeptical about anything that could affect their level of privacy. When you toss claims into the miss it can be something that takes time to determine how to do it right.

Keep in mind that not all applications out there really need to know specifically who a user is. All that is required is that something is used to keep the use of the application separated by user. You can even use a shopping cart to do this but even that is over the top for many applications out there today. For those that do have a per user requirement though that they track, you will definitely need to have some unique way of identifying every single user.

With traditional types of applications, there is a sign in name that is used to tell them from each other. When you have claims based applications in place though you will need to select what claims will be used to uniquely identify them. Then you will need to have the issuer set things up to give you the same values for them every single time that a user tries to access a given application.

It is a good idea to ask the issuer what claims they are set up to use for identifying users. When you use cross realm federation though you have to keep in mind that there is going to be more than one issuer involved. Each issuer does have it’s own URL that identifies it though. This can be used help with the process.

You will also find that all email addresses have some properties in them that are unique. This is why they are very good identifiers for claims. It is important that you realize you won’t have information about all of the users and claims out there for your application. When you go with cross realms you waiver that right of control in order to not have so much responsibility for your application.

Users are going to come and go using the token that they got from an issuer that you trust. With that token you will have information about who they are as well as what they have access to. Remember you don’t have to change your coding in order to support new users regardless of what realm they come from.

The issuer should be involved with the authorization decisions though. They shouldn’t be issuing tokens to any users that don’t have the credentials to access your application. Make sure everything is automated so that you don’t have to set up anything extra within your application. With a claims based application, you can give up lots of responsibility for the application. However, you do want to make sure you place that responsibility into the hands of a qualified issuer.

Share