SharePoint Claims Based Authentication Architectures Explained Part 5 SharePoint Identity Across Realms

We have already talked about claims based identity and how to design a claims based application where the issuer is able to authenticate the users directly. You can actually take all of this one step further though. The process allows you to expand the capabilities of your issuer to accept a security token from another issuer. This means the user won’t have to directly authenticate it. Now the issuer is able to issue security tokens and to accept them from other issuers that it trusts.

As a result you will be able to have identity with other realms in spite of the fact that they are separate domains of security. This is a powerful ability that offers plenty of benefits. The process is accomplished by using the IT staff. They get to determine how issuers are going to be configured. You do need to understand these possibilities because they are the entry way to even more features for your application. You won’t have to change your application in any way though. Some of the different possibilities can offer some flexibility for your application design too.

Being able to maintain an identity database doesn’t have to be a difficult task. You can have a simple database that keeps the usernames and passwords that you need to manage in place. However, it is common for users to forget such information frequently. Chances are you have a high level of security in place for your business. Therefore it isn’t acceptable for you to just email those individuals new passwords.

It is very difficult to successfully manage a database for remote users. Lets say that you work for a partner company with a purchasing application. An IT staff make changes to your account as you work in the purchasing department. The IT staff gives you the role of purchaser so you are given permission to use the application. How are people with a different company going to learn about you being transferred to the sales department? What happens if you decide to quit your job for the company?

The changes will need to be found out, but don’t count on the human resources department to send out any type of notification. It should be something that the company you were employed with would need to manage. Storing information for remote users is often looked upon as a liability so keep that in mind. Any data that you store about remote users could turn out to be a liability for your business.

Over the course of time the data stored with a remote user will become old. There are some safe ways that you can expose applications so that a partner business will be able to use them. One of these methods involves decentralizing the process. You won’t have an issuer that authenticates remote users directly. Instead you will set up a trust relationship with an issuer that is part of another company.

Your issuer trusts their issuer to authenticate the users that are in the realm. These employees are satisfied because they don’t need any type of special credentials in order to be able to use your application. They will use the same single sign on ability that they used in their own company. Your application will work for them due to the came pass to get in. The claims you have to get the boarding pass for the remote users will be less powerful though because they aren’t really employees of your company.

It will be the responsibility of your issuer to determine those assignments. Your application won’t need to change either when new organizations are added as partners. This is a huge benefit of using claims because it allows your configuration of only one issuer to be accessed by so many new users out there.

It is possible to use claims to decentralize identity. This is going to eliminate data from becoming stale for remote users. Another benefit is that the claims will allow you to logically be able to store data about your users. The data can be stored with authority and be convenient to access and to use. Through the use of federation, many of the road blocks out there are removed so that new users can come in.

Your company will need to decide which realms to allow access to your claims based application. Your IT staff will be able to set up the relationships that need to be in place for them. They can get employees in a business that use Java to access your application but they won’t need to issue new passwords. They will only need to have a Java based issuer. Also, anyone with a Windows Live ID would be able to use your application.

Share

SharePoint Claims Based Authentication Architectures Explained – Part 1 – Intro To Claims Architectures

You will find that the internet offers plenty applications that are interactive. This allows users to be able to access them simply by reading a hyperlink in text and then clicking on it. When this process is initiated, the information they seek more about will come up. The reader anticipates that the websites are going to monitor who is logged into them and for how long. No one wants to have to put in their password over and over again to be able to benefit from such a process though.

Instead they want to be able to enter it once and then to access any of those company based applications from it. It is very important for any such development that is created for the web to be able to support this need from the user’s point of view. It will be referred to here as a process called single sign on. You may hear it referred to out there though as passive federation.

Many people have had experienced with the world of Windows, and that is a single sign on concept that they use. Once you have logged in with your password the first time that day you will have access to all of the resources that are part of that hosted network. Windows is able to authenticate that password for each entity you wish to access. This is why you can avoid having to type it in again and again.

Kerberos is extremely popular but that has also resulted in it losing flexibility as a cross source. The domain controller is the one that has the keys to all of the resources that people within a given organization are able to access. There are firewalls in place that carefully guard such activities. When you aren’t at the office, you can access them through a VPN to the corporate network connection.

Kerbos isn’t very flexible when it comes to the information that is provided either. Many people would love to see it include arbitrary claims including email address access. However, that isn’t something that you are able to find at this point in time. With claims though you have such flexibility present. You are only limited in what you can access by two things your own imagination and the policies that your IT developers for the business have in place.

There are standard entities in place that allow you to cross different boundaries in terms of security. This includes both platforms and firewalls. They reason for this is that it makes it easier for it all to be able to communicate with the others. With this in mind, the application doesn’t have to verify the users.

Instead, the application needs to have a security token that is provided by the issuer trustee. When the IT department needs to increase security then the users have to use a smart card rather than a username and password for access. However, it won’t have to be reconfigured so that isn’t a time consuming process.

Even so, domain controllers will still be in place to offer security when it comes to the various resources of a given organization. There will be various issues for businesses to consider too. For example they will need to figure out how to resolve issues relating to trust. There are legal issues that have to be reviewed before entering into a contract with one is completed. You can be confident that claims based identity won’t change those needs that are already in place relating to such issues.

What will change though based on it is that there will be layers to the claims. Some of the barriers that are now in place will be removed. The result will be a single sign on solution that is also flexible for the needs of the users. Claims work is designed to be able to work within the security that already exists. It will eliminate many of the technical problems that are currently experienced.

Share

Implementing Pluggable SharePoint Single Sign-On

Implementing Pluggable Single Sign-On
One of the most overlooked aspects in previous versions of SharePoint was the Microsoft Single Sign On Service. This service for most people struck thoughts of a federated SSO mechanism by which one would gain a “one sign on for several applications” environment whereby all third party apps could be assimilated into the SharePoint environment using an arbitrary sign on mechanism.

This common misconception was the reason that the Microsoft Single Sign On service was passed over so heavily. Since it was originally tailored to pull orphaned data out of third party databases, such as SAP, Siebel, or other various LOB backend systems, not being able to sign onto them turned several parties off to the service.

The context of the service remains the same, however the natural power that it provided is still the same, and multiples even further when combined with new functionality such as the Business Data Catalog (BDC) whose main purpose is now to integrate those very LOB backend system databases. Using the native Microsoft SSO, it is possibly to eliminate the need to build complex identity impersonation in order to harvest business data out of those third party systems, but rather using its structure of Enterprise Application Definitions (EAD) one can build several pass through authentication channels by which that very business data can easily be assimilated and brought to a web front through the use of various WebParts, whether it is OOB, or a custom developed solution.

There are several considerations when setting up the SharePoint 2007 (MOSS) Single Sign On Service, and oddly enough, the most difficult of all the tasks isn’t the programmatic hooking of the data into various logic distribution mechanisms, such as a WebParts. One of the most difficult portions for various organizations to grasp was the actual process account setup, and then architecting the proper Enterprise Application Definitions so that the service can be leveraged properly, following, how one can use the powerful classes that exist within the SSO namespaces in order to procure third party forms sign on for a truly federated sign on environment.

The Default Single Sign On Service
Single sign on in SharePoint isn’t just running, the service is halted by default when the machine is started, and therefore you have to call up services.msc from a run and start it up. You will have to start SSO on your job server. Once you get started, the best next step is to start to plan out how you are going to configure the accounts for SSO, which are:

  • Configuration account
  • Single sign-on administrator
  • Single sign-on service
  • Enterprise application manager

You can pull up the exact criteria of what needs to be satisfied for each account. After the accounts are created you will create the encrypted SSO database where we are going to map and store our third party credentials. Once your database is created, and the encryption key is created, you can create your Enterprise Application Definition (EAD) which is going to define the structure, it says exactly how the retrieval of the credentials are going to be handled. The creation of that is pretty self explanatory.

Pluggable SSO Architecture
The Microsoft SSO Service API is independent of the specific authentication mechanisms that are discussed in previous articles. The unique feature of the new MOSS SSO is that the Microsoft Single Sign On service is now a pluggable feature, by which you can leverage whichever SSO provider that you would like, be it a custom one that you have made or one provided by a third party. When doing so, the default SSO provider, SpsSsoProvider, will no longer be used. Because only one SSO service can be used, it is a one or other choice. A MOSS administrator/architect has to decided whether they want to bind the default SSO provider or use one of there one choosing, each which carries its own implications.

Using SSO To Procure Forms Authentication Credentials Passing

Contrary to popular belief, it is possible to use SSO to sign onto other forms-based applications so that the backend credential cache can be used for more than just exposing business data into WebParts. Although this requires some development, it is a powerful feature that allows a fluid experience for your users. Using two separate webforms, along with some minor JavaScript to copy credentials after some code behind is run, this can be easily facilitated:

Firstly, we have to create a separate login form:

Login.cs

Creating the page load event

[csharp]

private void Page_Load(object sender, System.EventArgs e)
{
   Credentials x = new Credentials();
   string[] z = new string[1];
   string strUserName;
   string strPassword;
   try {
     Microsoft.SharePoint.Portal.SingleSignon.SSOCanaryChecker.AddCanary(Page);
     x.GetCredentials(Convert.ToUInt32(1), “<:Put Here EAD Your> “, z);
   } catch (SingleSignonException ex) {
     if (ex.LastErrorCode == SSOReturnCodes.SSO_E_CREDS_NOT_FOUND) {
       return;
     } else {
       throw ex;
     }
   }
   Server.Transfer(“webform1.aspx”);
}

[/csharp]

Event Handler For Submissions

[csharp]

private void Button1_Click(object sender, System.EventArgs e)
{
   Credentials x = new Credentials();
   string[] rgSetCredentialData = new string[2];
   rgSetCredentialData(0) = uName.Text;
   rgSetCredentialData(1) = PWD.Text;
   Credentials.SetCredentials(Convert.ToUInt32(1), “<:Put Here EAD Your> “, rgSetCredentialData);
   Server.Transfer(“webform1.aspx”);
}
}

[/csharp

Webform1.cs
Creating the page load event

[csharp]

private void Page_Load(object sender, System.EventArgs e)
{
   Credentials x = new Credentials();
   string[] z = new string[1];
   string strUserName;
   string strPassword;
   try {
     Microsoft.SharePoint.Portal.SingleSignon.SSOCanaryChecker.AddCanary(Page);
     x.GetCredentials(Convert.ToUInt32(1), “<:Put Here EAD Your>”, z);
   } catch (SingleSignonException ex) {
     if (ex.LastErrorCode == SSOReturnCodes.SSO_E_CREDS_NOT_FOUND) {
       string strSSOLogonFormUrl = SingleSignonLocator.GetCredentialEntryUrl(“<:Put Here EAD Your>”);
       Response.Redirect(strSSOLogonFormUrl);
     } else {
       throw ex;
     }
   }
   strUserName = z(0);
   strPassword = z(1);
   TextBox1.Text = z(0);
   TextBox2.Text = z(1);
}
}

[/csharp]

The portion that isn’t handled with the above is that it will work fine if a user has entered, or currently doesn’t have credentials stored, but not if there password has changed, to build this in you would also have to call error codes, something like this:

[csharp]

SSOReturnCodes.SSO_E_CREDS_NOT_FOUND = ssoe.LastErrorCode

[/csharp]

You would then have to do a redirect using something like:

[csharp]

SingleSignonLocator.GetCredentialEntryUrl

[/csharp]

Then you could handled it. For the actual submission of the credentials, I just use JavaScript to paste them into an impersonated box for submission. One would have to fill in the programmatic name of your EAD between the <> in the codebehind forms for this to work properly. The important methods in here are getcredentials(), which will attempt to fetch the credentials, and setcredentials(), which will set the credentials.

Share