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.


Why Should I Care About CardSpace and SharePoint?

I get asked this question pretty frequently, considering I am trying to push the SharePoint community to use CardSpace in their SharePoint environments. Well, at least I am trying to get people to consider CardSpace because it will pay an intrinsic role with Windows users (which I care about because I’m a SharePoint architect) when we get to the point of identity metasystem realization.

< rant>

Well, the first reason you should care about the concept that CardSpace is identity theft is an insanely large and every increasing problem. Just browse the following news article:

Identities are gold! They are worth money!

People ARE making money off identities; we should be looking at all the options we can offer to our SharePoint users so that their sign on experience is fluid, protected, and secure in transit. Our biggest concern is our users, we MUST protect our SharePoint users! What is a collaboration system without users? What is an EIM (Enterprise Information Management) solution that people don’t trust? It is vacant, void of activity, and generally worthless.

Although the .NET framework offered us great mechanisms for doing all sorts of great things in the realm of cutting down on development time for certain business requirements and making things prettier, CardSpace is playing a piece in a solution that will solve things that prevent malicious intent. This is entirely more important than any other functionality! We are looking at targeting things that stop crimes, decrease the amount of lost business revenue due to malicious intent and actions, and taking care of what we care about the most, our SharePoint users! We are attempting to introduce solutions that solve problems that make headline news, that really cost people things that they have worked for in their lives, and protect our organization.

Secondly, you should care because an identity metasystem is not just a neat feature that might happen. It is going to happen IMHO. It is the natural evolution of security; it is how things eventually should be. Although participation by a large amount of parties is required, that involvement will snowball and it will become the parties who do not participate whom belong in the minority. Am I being optimistic? Maybe. I guess it is in the eyes of the beholder.

Furthermore, one thing that people are always interested in doing is promoting the use of SSO (Single-Sign On) to orphaned business applications using SharePoint as an entry point. This is for good purpose. Most people implement SharePoint as their intranet framework because of its inherent document management functionality and collaboration technology. It makes sense to also use it as the POC for all the other foreign application introduction that are available within a corporate environment.

The SharePoint SSO (SpsSsoProvider) provider that is provided OOB is not a real single sign-on provider, in the sense that SharePoint SSO although will be able to store credentials in an encrypted database and pass them to backend business applications (after setting up the relevant service accounts, setting up the relevant Enterprise Application Definitions, etc.), is meant for consumption within objects like WebParts (this is why this authentication type is provided when configuring things like the DataView WebPart within the interface). With CardSpace, we are looking to do something more, although the SharePoint SSO system will stay play an intrinsic role in the overall verification architecture, we are trying to provide an identity solution that will aid the entire corporate system, and will also touch on the realm of allowing our users to securely sign on to websites that provide services like banking, shipments, purchasing, etc. that they might encounter in their typical day job. You know, things that would prove normally profitable for a malicious user to otherwise compromise.

Although there are ways to use SharePoint SSO to sign onto other applications with some custom code (as detailed in this post on the main ARB site), it is not something that is exactly plug and play, there is some development time and architectural considerations to take into this argument before making that decision. The solution that I presented in the referenced above article is more of a hack than an actual enterprise solutions.

< / rant>

Sure, there are going to be bumps along the road. Someone is going to find an exploit in CardSpace, but what product doesn’t have their bugs? I hope Microsoft encourages this, as it will do nothing but enhance the product. In any respect, don’t disregard CardSpace for your SharePoint environment. Embrace it, stay on the cutting edge with advanced objects like these that the .NET framework provides natively to you. Exploit them to the highest potential, as we must consistently ensure that our SharePoint users are as secure as possible!