SharePoint Claims Based Authentication Architectures Explained Part 7 Transforming Identity In SharePoint

The role of the issuer involves taking the incoming identity and making it into a secure token that can be used for a given application. The token is very similar to a boarding pass it has pertinent information about the identity of the user. The only information that is on it is what the application needs. This is why such boarding passes often have a role that can be used immediately. This is faster that relying on Windows groups.

The issuer is often thought of as an identity transformer. It is able to convert the incoming identity into something that is readable to the application. There are users that can have one sign on credential that allows them to access all of the different application they may need. This is because there is an issuer in the realm with the trust to authenticate all of them.

There is a local issuer that offers claims to applications in their own realm as well as to those that are in others and need access to multiple applications. It allows them to use their local applications and those that are remote all with just that one credential being in place rather than needing one for each of them.

The Active Directory Federation Services (ADFS) relies on a rules engine that will support the claims transformation. They have a set of rule in place that say when a claim of X type is make with X as the value then issue this type of claim. For example you may have an application called Managers that allows special access to certain features. This claim will take that user to a Mangers group in the realm. That is where they will always be sent.

A partner group may have a group called Supervisors that needs to gain access to that Mangers area in the application. Through the transformation process both the Supervisors and the Mangers can access it as long as the issuer has trust for this to be acceptable. This is all possible due to the way in which the rules are written in the ADFS. The issuer has to be designed to support these types of transformations because the terminology used in each company can be very different.

Hopefully you now see what is possible with the concept of cross realm federation. Here are the steps involved with a browser based application:

  • A user in a remote realm clicks a link that will take them to your application
  • That user is redirected to your local issuer
  • The issuer redirects the users browser to the issuer that is in their realm.
  • The local issuer authenticates a token, sending the user’s browser back to your issuer with the token
  • Your issuer will validate the token, transform the claims, and then issue a token for your application to be used
  • Your issuer sends the user’s browser back to the application with a token that has the claims your application needs on it

In step three you may be wondering how the issuer knows that the user is from a remote realm. Why doesn’t it think that she is a local user and thus attempt to authenticate her directly first? Of course by doing so the user wouldn’t get in and they will be upset about it. Also, how does the issuer know that the user is from one particular realm versus another?

You will have more than one partner and so all of them will be differentiated out there. The home realm discovery is where the issuer has to determine if the user is from the local realm or one of the partners. If that user is local then they can be authenticated directly. If they are remote then the issuer has to be able to find out what the URL is to redirect her to so that they can be authenticated by the home realm issuer.

There are a couple of different ways in which this situation can be handled. The first one is for the user to help in some way. When the browser of the user is redirected to the ADFS, it will stop the protocol and display a web page to the user. Here they will be asked what company they are employed by. The credentials in place are only good for one company per user so they can’t give you false information here and continue to with any hopes of gaining access.

Once the user clicks the link for the company they are with, the protocol will continue the process. The issuer will know what to do from there. You can also set it up so that the user is only asked which company they work for one time. After that there can be a cookie in the browser that will always display that information without it being asked for in the future.

There is another way to handle this and it involves adding some type of hint to the query string in the link that the user clicks on in the first step. This query string is called whr with the hr being representative of home realm. It is a good idea for the IT department to ensure all of the links to remote applications include this information. That way the application is more user friendly. At the same time it will protect the privacy of the company as it doesn’t require revealing who all of the partners happen to be.

The issuer is going to find this hint and then map to the right URL for the home realm of the user. This means they won’t need to ask the user who their issuer is because the application is going to use the information it has available. A cookie will be in place to make sure users don’t have to take time to answer such questions.

The best way to get the users help for web applications is through the use of a web page. They are going to be interactive and the browser will conveniently be able to display a home realm discovery page when necessary. You may be wondering how to take care of this when it comes to web services and even your rich clients? Information cards can be a very useful tool for such circumstances.

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

Building Forms without Forms Services – Introduction

For some organizations, it is not possible to use Forms Services either as an architectural or budget constraint. Therefore, other avenues of development must be considered when looking to move to a paperless form process with zero footprint form fill-in capabilities. When not using InfoPath and Microsoft Office Forms server, a traditional solution is to build forms using standard WebPart development techniques, submitting the data to either a corporate database or to a SharePoint list for storage.

The ordinary approach to custom forms development in SharePoint is to construct a custom WebPart for data submission by instantiating all the required .NET controls needed on the page, binding the controls with some sort of validation logic, and then submitting the entered data to a backend data store such as SQL Server by using an event handler to call a SQL stored procedure. This development process necessitates diligence from development to production code release because binding the controls to the WebPart doesn’t allow the use of an interactive, intuitive Surface Designer that Microsoft InfoPath would normally provide. As an example, I will demonstrate building a simple SharePoint WebPart that could be used to submit an ID code to a small backend SQL table and could eventually be used as a boilerplate for more complex data by appending some additional logic.

In order to build the form WebPart using solely inherent WebPart functionality, there are several steps that must be taken. Some of these steps will setup the necessary class files for assimilation into the WebPart framework; however a great majority of the code you will write will provide the necessary logic in order to gather user information, and push the harvested data into a backend storage system. The most typical of these is a SQL database; therefore we will closely examine how to use ADO.NET 2.0 to call a T-SQL stored procedure to manage the data submission.

  1. Set up the WebPart class
  2. Declare Variables, Assign Controls, And Set up Exception Management
  3. Setup the Connection to the SQL Server with ADO.NET 2.0
  4. Setup the Validation Controls
  5. Wiring the Submission Event

Each of these tasks is explained exhaustively in the following detailed sections. The end result is a Forms WebPart that targets a common InfoPath task, putting a Text Box control onto a WebPart page, which can then be used in order to submit data to a backend SQL database.

Share