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 8 Design Principles for Claims Based Applications

It can prove to be difficult to give guidance in the area of designed claims due to the fact that they work independently off of a given application. This next section is going to help answer questions you may have though and to offer a look at some different approaches you may want to consider implementing.

The Fundamentals of a Good Claim

There isn’t always a clear answer when it comes to the design for claims based applications. This is why it is important for you to understand the different variables and the tradeoffs that each one of them can offer you. With these examples though you should get a solid understanding of what types of elements need to be present in order for you to have a good claim.

The email address of the user is one thing to consider. When you have a candidate for a claim in a given system an email address is a good way to identify them. Just about everyone out there has an email for business purposes and it will be required for you to federate identity across realms. With an email name, you will be able to get your system personalized for each user.

There is some personalized data that can be used too. For example a user may have a specific skin or theme that they wish to use for a website. This is also a type of date that is specific for a given application. Choosing a skin or a theme here doesn’t make sense because it isn’t part of the users identity according to the verification process. Therefore this should be managed as a whole rather than individually.

There are users that will have permission to access date in your application. It can make sense to model permissions as claims but you nee to realize that soon you may end up with too many of them within your levels of authorization. A better way to handle such issues is to develop a boundary that will separate the authorization data from claims and that which you can handle another way.

A good example is that you have a cross realm federation that can be a benefit by allowing realms to be authorized for high level roles. The application will map these roles into fine detailed permissions with various tools. A common one used is Windows Authorization Manager. You do need an issuer that is designed to handle this fine detailed permission process though so that you can keep your claims at a higher level.

Here are a couple of questions that you need to ask before you go about attributing a claim:

  • Is the data going to be a core part of what I use for identity?
  • Will the date be used by only one application or several?
  • Will an issuer manage this data for me or should I have it handled directly through my own application?
Share