Working with identity in SharePoint can prove to be very complex and thorny, cultivating a need for technology to provide simplified paths. It can certainly be uncomplicated in specific circumstances when there is only a single entity that is accessing SharePoint, such as when Kerberos (provided by Active Directory Domain Services ([AD DS]) is leveraged. Where the complexity starts to come in though is when more information is desirable. Not all SharePoint applications can be ran within the context of Kerberos or by having someone delegated a username and password. This is further complicated when SharePoint needs to be accessed both internally within the enterprise and externally on the cloud by customers. There are also times when someone in the business needs to access an application at a remote office or outside source, allowing them to do so with the same method of accessing it devoid of having a separate login is critical.
The answer to all of this is to have an indistinguishable approach that fits all these scenarios, with a single method in place meeting typical industrial computing standards of the business world. It needs to have clear boundaries but also be flexible enough so that it won’t soon be outdated or inextensible. It has to be something that can be implemented on many levels including the different products that vendors and developers alike can use. Claims based identity is meant to supply the solution to this type of difficulty.
Next Section >> Claims Based Identity
There are abundant, diverse types of SharePoint software being produced incessantly. When we employ it, we habitually take for granted what has gone into the development of it. One of the principal decisions is what type of identity will be utilized as there are numerous that the SharePoint technology of today can offer. It can take time to establish which one is best for a known type of software requirement.
Some of the things that have to be taken into consideration include who will be using the materials, how they will be used, and more. As a result of the multiple uses of some SharePoint software it may be compulsory for one that one identity to be used, allowing plenty of options for how it will be applied.
While it is the SharePoint user that will resolve what accessed based on behavior in SharePoint, there is also a great deal going on behind the scenes. SharePoint may need to be able to gain user information from various resources, not solely a known, compliant directory. It is with such problems in mind that the scheme was fashioned to develop an identity that is able to work regardless of what a person or a business needs, transversing multiple types of barriers allowing SharePoint and related applications to be able to have requisite identity information in a proper, consumable format. The issue of tracking it down would be eliminated from the equation. This is where claims-based identity comes into the picture. It offers a practicable solution so that identity information can be gathered from both inside and outside of that entity. It additionally allows it to be harvested from the cloud.
Through a claims based approach everything is simplified from the developers point of view. That consecutively means it is going to be less expensive for a particular SharePoint application to be constructed, while impacting maintenance costs by moderating costs relating to the upkeep of these programs. Owing to these facts, many SharePoint developers are earnestly looking at exploiting the value of claims based integration.
As you read this material you will start to appreciate the fundamentals of claims-based identity by explaining the technology being exercised by Microsoft to create this concept, known as the Geneva stack. Some of the things that need to be explored include the Geneva Server, Windows CardSpace Geneva, and the Geneva Framework. They all optionally work together to make claims-based identity work in reality as it does in premise. Right now these programs are in testing modes, keep in mind that some aspects of what you read here could change before they final release is done.
Next Section >> Working With Identity in Applications
I wrote these posts ad-hoc because I have recieved this question more than anything else lately, likely due to the paradigm shift from legacy authentication technniques in SharePoint 2010. I tried to keep the language in localizable terminology in order to support the mult-lingual functions provided on the site as well. I broke it up into seperate posts as well to provide some level of categorization, some are big, some are small.
I know they might not be perfect, but it’s a beta-ish technology and writing 16 posts takes a fair amount of time. Along those lines, there might be some terminology interchanging going on because I was using the Geneva stack when I had started this. Just keep in mind that the following legend coordindates the Microsoft code names:
Active Directory Federation Services (ADFS) = Geneva Server
Windows Identity Foundation = Geneva Framework
Windows CardSpace = Windows CardSpace :)
- The Basics of the Identity Foundation
- Working With Identity in Applications
- Claims Based Identity
- Claims Creation
- How are Claims Used?
- What does ADFS v2 And Windows Identity Foundation do?
- The Relationship Between Claims Based Identity, Windows Identity Foundation, ADFS v2
- Claim Usage Within The Enterprise
- Claims Usage Between Enterprises
- Claims Usage On The Cloud (Internet)
- Delegating Claims
- Geneva Server – ADFS v2
- Self Issued Identity Providers
- Geneva Framework – Windows Identity Foundation
- Conclusion On Claims Authentication