Access Control Service as a Federation Provider

The first scenario we are working is using ACS as a federation provider. This is an extension of the current chapter on Federation.

The basic scenario is the following:

• Adatum has an Order processing app (a-Order) that is already claims enabled.
• Adatum wants their partners to be able to access a-Order with their own identity infrastructure

 

In pictures:

1. Adatum Issuer (ADFS in the example) now trusts Litware issuer with whatever method Litware has implemented. If Litware uses AD, then a good candidate for their Identity Provider is ADFS of course.
2. Rick authenticates with their IP and gets a token for Adatum
3. Rick (or his browser really) sends the token to Adatum’s issuer where it gets transformed into an “Adatum Token”. This is an opportunity for Adatum to translate  Litware concepts into Adautm ones: for example Rick might be in a “Sales” group in Litware, but a-Order has no notion of “Sales”. It might understand a role “Order Tracker” instead. The Adatum issuer will translate “Sales” into “Order Tracker”
4. If everything goes well, Rick (his browser) gets an Adatum token and finally sends it to the a-Order

 

Note: This flow is really the “unwinding” of the process that starts when Rick browses a-Order. Everything really starts there (look for WS-Federation “passive profile” for more info), but conceptually that’s what’s happening.

Let’s imagine now that Adatum does business with other partners (smaller companies than Litware maybe) that do not have any identity infrastructure of their own. Let’s imagine “Mary Inc” is a a very small busniess owned by Mary, and she essentially works from home. Mary is probably not going to have AD under her desk.

What are the options for Adatum if they wanted to open a-Order to customers like Mary?

 

Option 1 – Adatum creates an Identity Provider for customers with no Identity Provider of their own

This is essentially deploying an Identity Provider (with its corresponding user database) for partners. Mary would get an account with Adatum  and she would sign on with the Adatum provider credentials.

 

They can implement it in various ways: use ADFS V2 with a separate AD, use ADFS v1.1 with ADAM, use a custom STS with ASP.NET Membership (e.g. the StarterSTS or similar), write their own (a fun project indeed).

However, there are quite some disadvantages in this approach:

1. It requires Adatum to develop/deploy additional infrastructure and maintain and support it. (Hints: what happens if Mary forgets her Adatum password? who is she calling? who pays for that support?)
2. Mary’s account is unlikely to reside in Adatum’s corporate AD (it will probably be a separate domain). Consequence: more servers, more licenses, more money, more power consumption, more greenhouse gases, less ice in the arctic, less polar bears…you get the picture.
3. Mary has acquired an additional username/password that will end up on sticky notes on her desktop monitor. Less security, worse user experience, less satisfaction with Adatum, more blame, less business, more complaints, increased need for selective serotonin reuptake inhibitors….not good.

 

Option 2 – Ask Mary to deploy ADFS

This would be just great, wouldn’t it?  Riiiiight…. I’m just kidding, please don’t attempt this.

 

Option 3 – Leverage any of Marys’ existing identities

Mary is on Facebook (sometimes too much).  Mary has a Hotmail account. Mary uses Google Docs. Wouldn’t it be great to simply use one of these? Yes, it would be great. How do we make that happen?

The answer is simple: make Adatum’s Federation Provider trust all those identity providers, just as they did with Litware:

 

 

Conceptually this is all fine, but it would be too easy,

The only issue is that often, all these providers implement different protocols and token formats: OpenID and OAuth and SWT, etc. So Adatum’s FP would have to understand all these protocols and formats and translate them into the ones a-Order understands (SAML & WS-Federation). If Adatum deployed ADFS as their FP this means that it can deal with WS-Federation, WS-Trust and SAMLP protocols and SAML tokens. Anything else requires extensions, development or additional infrastructure.

The good news is that all this supported out of the box by ACS! And the solution would look more or less like this:

 

 

 

 

Advantages:

Adatum reuses all the internal infrastructure that they’ve invested in already. The setup of all this would probably take hours (or minutes even) as opposed to weeks or months. Adatum can rely on an highly scalable, secure, proven, global service as opposed to rolling out their own.

Using a cloud service means less control though. Adatum will have to trust (beyond the identity meaning) Microsoft to run this for them. They will also have to rely on any of the 3rd party identity providers to authenticate the users. If Facebook is down for whatever reason, then Mary will not be able to access a-Order. But I guess that if Facebook is down, the world has bigger problems, right?

Comments

• Anonymous
  February 14, 2011
  Eugenio: for step 2 at top it states that "Rick authenticates with their IP and gets a token for Adatum" - wondering if that is really a Litware token (until step 3)?

• Anonymous
  February 14, 2011
  Yes, it is a Litware token, for Adatum as a Relying party. I meant that the token Litware issues has a specific destination: Adatum's FP. Makes sense? Thanks for the clarification. I can see it could be confusing. Eugenio

• Anonymous
  February 15, 2011
  Eugenio, Below the 3rd image, you meant to say "Conceptually this is all fine, but it would not be too easy"?