Identity

Identity is a common problem for connected systems.  Who am I? (AuthN) and What should I be able to do? (AuthZ) are fundamental questions to answer for every software solution.  In the world of SharePoint 2010, Claims Based Authentication (CBA) and Active Directory Federation Services (ADFS) 2.0 tie in to those questions in unique ways.

I am going to talk about these topics in a series of blog posts. This post is Part 1.   My goal is to not only cover the “what” and “how” of getting these technologies working in a SharePoint 2010 environment (which will include Office 365), but to explain a little bit about what they represent, what the business advantages are of using them, and how they work together between themselves and with other external systems. 

Claims Based Authentication

Claims Based Authentication (CBA) is a new feature bundled into SharePoint 2010.   Microsoft Technet literature says of CBA:

“SharePoint Foundation 2010 incorporates a new authentication model that works with any corporate identity system, including Active Directory Domain Services, LDAP-based directories, application-specific databases, and user-centric identity models.” - http://technet.microsoft.com/en-us/sharepoint/ee518670.aspx

The idea behind CBA is to make authentication and SharePoint easier by implementing some standards that are emerging surrounding identity, such as SAML, WIF, and the WS-* standards.  CBA is seen for the first time in SharePoint 2010 in all versions of the product including the free Foundation product.   CBA offers the ability to do things like authenticate against Windows LiveID, other systems such as OpenID, LDAP based directories, or open source federated authentication systems such as Shibboleth implemented in other operating systems and on other technology stacks.

Why is this important?

CBA is identity’s road into the future.   While easily-set-up examples aren’t as abundant out of the box now, and while SharePoint 2010 still supports the tried and true authentication methods of NTLM and Kerberos a lot more flawlessly than the CBA implementation in this version, the world of identity is marching on towards open standards based systems, and CBA is directly on that road.  Standards allow authentication to bridge vendors and operating systems, and in a connected world of cloud computing this becomes more and more important.

What is ADFS 2.0 and where does it fit in?

Active Directory Federation Services (ADFS) 2.0 is Microsoft’s toolset to federate identity.  Technet literature states:

“Active Directory Federation Services (AD FS) 2.0 helps simplify access to applications and other systems with an open and interoperable claims-based model. The AD FS 2.0 platform provides a fully redesigned Windows-based Federation Service that supports the WS-Trust, WS-Federation, and Security Assertion Markup Language (SAML) protocols.” - http://technet.microsoft.com/en-us/library/adfs2(WS.10).aspx

OK, you say, but what does that mean?  Maybe these words to you are only concepts currently.  Maybe you’ve read through a lot of content on Technet and ADFS 2.0 doesn’t seem to simplify a whole lot.  It’s a lot more complicated than just setting up SharePoint with NTLM or Kerberos, for example.

While that may be a fair criticism or assessment right now, let’s go back up to that big picture for a moment.  What is federation in general?  The most common definition is “the act of federating or uniting in a league”  This presents the general idea, and the technical definition also clarifies further – “A federation is multiple computing and/or network providers agreeing upon standards of operation in a collective fashion”.  While federation in identity is still in its beginning stages, this is the method that absolutely will need to be used to connect systems based upon disparate technologies. 

We see federation in a couple places starting to creep into SharePoint.  One of the first is in Search – where we can start to bring in results from crawling other non-SharePoint sources and have them produce similar results to searching SharePoint sources.

The second place federation is coming in is right here in the identity world.  ADFS 2.0 works in the most simple fashion as a claims producer and a claims consumer.  

As a claims producer (termed “claims provider role” in ADFS terminology), ADFS 2.0 can authenticate a user against a back-end claims store and issue a certificate that can be passed along to an application for identity purposes.

As a claims consumer (termed “relying party role” in ADFS terminology), ADFS 2.0 can process and trust claims from other claims providers.  After validating the claim, it can reaffirm the claim to its relying parties (such as a SharePoint 2010 application).

What kind of back-end systems can ADFS 2.0 help me authenticate against?

ADFS 2.0 as of this writing has a number of white papers that highlight example implementations of federated authentication against several back-end stores, including IBM Tivoli, Windows Azure, SharePoint 2010, PingFederate, the Microsoft Office 365 beta, Oracle Identity Federation, Shibboleth 2.0, and CA Federation Manager.   As you can notice, several of these represent vastly different technology stacks.  More details of this can be found here:  http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(WS.10).aspx

What scenarios could ADFS 2.0 help me in my SharePoint 2010 environment?

Goals for ADFS 2.0 in general can include the following:

• Provide your AD Users access to your claims aware applications
• Provide your AD Users access to applications and services in other organizations
• Provide other organizations users access to your applications

These goals maps to the following ADFS 2.0 Designs:

• Web Single Sign-On (SSO)
• Federated Web Single Sign-On (SSO)

The general goal of providing your AD users access to your claims aware applications when you consider SharePoint doesn’t really gain us a whole lot.  Our AD users ALREADY have access to SharePoint through NTLM and Kerberos. 

However, from a SSO perspective where you can provide your users access to other applications and services in another organization has a unique SharePoint application:  Office 365 uses ADFS 2.0 to provide SSO capabilities and you can utilize your on premises ADFS 2.0 implementation to tie into this, as highlighted in the Beta here:  http://onlinehelp.microsoft.com/en-us/Office365-enterprises/ff652540.aspx 

Another key point as it pertains to SharePoint is that you can authenticate users that are external to your organization, or external to your corporate intranet through ADFS 2.0 and provide them access to your SharePoint 2010 environments through CBA.

So in conclusion, this is an introduction to the topics of SharePoint 2010, Claims Based Authentication (CBA) and Active Directory Federation Services (ADFS) 2.0

Stay tuned for further details of how these work together in future blog posts.