identityjunkie.com

This weekend, I had the chance to hang out at a .NET users group here in Southern California where I found myself spending part of the evening explaining how Active Directory Federation Services (AD FS) and ForeFront Identity Manager 2010 (FIM 2010) complement each other in the grand scheme of things we all refer to as “identity.” 

Thinking this might be worthy of a blog post, I thought I’d share the discussion.

AD FS provides Web SSO for on-premise and internet browser based applications. FIM 2010 provides enterprise identity management in the form of provisioning, synchronization, and workflow. Both are products of the Microsoft ForeFront Security Suite.

Not yet getting into anything heavily technical, let’s look at the immediate value both technologies bring to the table.

1. Externalized authentication to a single service (brokered authentication)
2. Automated data exchange (the process of managing the identity – provisioning/deprovisioning of accounts). This is can also encompass the process for authorization (AuthZ).

When talking AuthN and AuthZ, these are different concepts but related. AuthN tells us who you are and AuthZ tells us what you are allowed to do. These topics can get pretty deep because there can be overlap between products in terms of the way authorization can be handled. For now, I’m just looking to explain how an operational process for managing the identities can be created using these two technologies.

In future posts, I’ll go more into AuthZ in terms of RBAC via FIM 2010 and ABAC via claims in Windows Identity Foundation.

The overall procedural concept is fairly easy…users should be able to authenticate once and access many (only what they are authorized to) without having to re-enter credentials; however as IdM professionals we need to ensure the end-to-end process is facilitated in a very secure manner.

Considering both the entire lifecycle of the user and the end-to-end authentication and authorization process is key in delivering either an SSO or provisioning based solution.

AD FS 2.0 Authentication Break-down

A. Once a user logs into their corporate network, AD FS can securely process an authentication request to target applications (on-premise or cloud-based). No individual passwords are necessary and no additional logins are required. The technical break-down of the process is:

1. Client (requestor) initiates RST from IP-STS.

2. STS authenticates the requestor and issues token with claims from various attribute stores. Claims provide authorization data for applications. The STS digitally signs the message for transport.

3. The token is returned to the client browser in which they will be redirected to the URI of the destination application.

4. RP-STS validates the authenticity of the token by the digital signature and then consumes the token and claims; therefore allowing the user into the application.

FIM 2010 Data Exchange (User Management) Break-down

B. It is very common for applications to require some kind of data exchange. This is especially typical for SaaS type applications. Here, FIM 2010 is extended to handle these data exchanges and to manage identities outside the firewall by automating the creation and management of identities into these target systems that reside in the cloud. Note: No passwords are synchronized across the internet.

5. FIM will automate the process of user creation, deletion, and modification processes through either a secured flat-file data exchange or through an XMA that interfaces public APIs provided by the SaaS vendor; therefore reducing administrative overhead and insuring consistency throughout all applications; locally or internet hosted.

With the ability to write custom workflows in FIM 2010, we can now develop better processes to determine weather users should even get an account provisioned in the cloud. And of course, the most important is to control the revocation of accounts in the cloud. Feel free to comment if I have missed something or have a question on the architecture.