Basics: Federation IS NOT Authentication

Commentary

Technology goes at a fast pace, unfortunately for IT professionals we are too busy at work to sit down and sharpen their skills.  Understanding the basics and frameworks about technology really can make a difference, however, I'm increasingly frustrated because I notice that even at architecture-level conversations I notice major knowledge like, knowledge of the problem, requirements, framing the conversation around security, understanding the basic standards and protocols.

How are you supposed to make technology decisions for organizations when you don't understand the basics?

Back in the day when I was a systems administrator,  I remember studying the inner works of Microsoft Exchange.  The framework was very basic, a client-server model that included

• Storage Providers
• Address Book Providers
• Messaging Transport Providers

This meant that when somebody was pitching to me a Fax solution that integrated with Exchange, I knew the key questions:  

• For usability - how does the fax addressing system integrates with the GAL
• For implementation - are there any client components?
• For troubleshooting - how do faxes get routed?

Another example in networking is the OSI and TCP/IP models.  I remember the good old Cisco Book by Oppenheimer "Internetworking Technologies Handbook" (I still recommend it) - basic things like in which layers flow control is important (layer 2) gave any IT professional a framework of what capabilities corresponded to each protocol.

This post is about the differences between Authentication and Federation.  Unfortunately when talking to folks that are looking at User Suite it's quite common for them to intermingle these terms.

What is Authentication?

Authentication is the process of verifying that a subject or program is who they say they are.  Notice the sequence here.  The's an assertion (who you say you are) and what are called "factors":

- Who you say you are  (username or unique identifier) - this is constant.

- Something you know (a password or paraphrase)

- Something you have (a physical token, smartcard, or one-time-password mechanism)

- Something you are (the patterns in your fingerprints, retina or voice)

Authentication happens directly.  There's a directory (like AD) that has a database of users and unique identifiers (UPN or sAMAccountName in AD), a password verification and protocol for authentication (Kerberos).   It happens every day, when you press Ctrl+Alt+Delete and type your password, when you access a file-share and silently get authenticated via Kerberos.  Strong authentication can be enforced by combining factors:  E.g. Something you know (password) + Something you have (hardware/software one-time token).

It happens when you go to Amazon, Facebook or when you do online banking.

What about Federation?

You've all seen the acronyms:  IdP, RP, SAML, Assertion, XML, etc.   What does it mean?

The best way to explain federation is to use an example.  

Let's introduce Joe Smith, he has a plane a reservation to Sidney Australia via Oceanic Airlines  (I wouldn't recommend that airline given the events in LOST), the sequence is typically as follows:

1. Joe Smith arrives at the airport and goes to the Oceanic ticket counter
2. He makes the following claim or assertion:  My name is Joe Smith and I have a reservation to Sidney, hands over a printout with this assertion, it includes a seat number and class.
   Let's think about this.  The ticket clerk does not hand Joe his boarding pass because the level of assurance that the information is accurate is very low. After all, somebody may be trying to impersonate Joe or he may not even have a reservation.  What if he arrived late or in the wrong date (this is known to happen).
3. The ticketing clerk confirms part of the assertion - Joe Does have a reservation, not only that, he is entitled to a premium seat 42B.
4. At this point, the clerk decides to confirm the other part of the assertion:  Joe's identity.  She asks, "can you please provide me with your passport?"  - because this is an international flight, the clerk verifies the Photo, Name/Last Name, DOB and Passport expiration date.  These fields have to match the system;  she checks Joe's face again, and proceeds to issue a boarding pass.
   Now, let's think about what happened here.  
• The airline can't confirm directly that Joe is who he says he is.  
• The airline relies on the US government's Passport Office's process and that they did their due-diligence in making sure they issued the passport to the correct person.  This makes the USPO the Identity Provider and the airline is the Relying Party. The airline has a trust relationship with the USPO.
• This means that the process in the USPO performs the authentication that Joe is who he said he was prior to issuing the document.
• The ticket also includes an entitlement.  Joe is entitled to seat 42B in the economy section.

This is Joe Smith's Boarding Pass.  Once his identity is verified, he'll be issued one.

Now we can look at the way Identity Federation is implemented in the the context of SaaS applications:

SaaS applications and many on premise applications can authenticate users directly OR support federation via a popular protocols like SAML.  This means that they can be a relying party.  When configuring an application for Federation, you'll be asked about the building blocks like:

• Certificate:  This is a key building block for a federation agreement or trust relationship.  The identity provider and the relying party establish the agreement by using a publicly rooted certificate.  If this certificate expires, the federation trust is broken.
• Assertion or claim details:  how is it going to be composed?  It could be as simple as a username or email address, or as complex as email, role, purchasing level, etc.  It's all based on the app.  In addition, a schema (XML) that provides the definition of assertions may need tob e provided.
• Redirection URLs:  Where to forward the encrypted claim or assertion;  This could be login, logout or error.  These typically are the Identity Provider's URLs to process the assertions and handle session or error management.
• Provisioning options:  Some apps support provisioning models like SCIM. More on this on a later posting.

It's important to understand that many SaaS apps allow mixed scenarios in which they can authenticate locally or using Federation at the same time.

How it works - just like the airport scenario, but online.

1. The subject or user attempts to access the application by providing an assertion (e.g. email address or username, e.g. joe.smith@corp.contoso.com)
2. The application (relying party) looks at its internal rules and sees the federation rules for that user.  Assuming SAML.
3. The assertion is encrypted and forwarded to the login URL to be processed by the Identity Provider.
4. The identity provider performs its internal checks (is the user active, allowed to access the app, etc - all based on the assertion)
5. The identity provider returns the verification result and any additional information required.
6. The subject is granted or denied access to the application and maybe depending on the application, information about entitlements may also be provided.

Here's the mapping of the Add Application Wizard for Centrify to enable SAML Federation for Salesforce:

Centrify User Suite - Application Wizard for Salesforce - it takes literally minutes to set up.

Centrify User Suite leverages Active Directory on the customer's premises to perform the validation or authentication, this means that the enterprise keeps control of key directory attributes and password data.

Recommended Reading

A Guide to Claims-Based Identity and Access Control, Second Edition

Although Microsoft-centric, the book does a great job and uses very good examples.  It's a free download (see link) or you can always get the hardcopy.