AD FS provides Web SSO for on-premise and internet browser based applications. ADFSv1 is available in Windows Server 2008. ADFSv2 which is supposed to be much more powerful, will be released at the end of 2010Q2.
FIM2010 provides enterprise identity management in the form of provisioning, synchronization, and workflow. FIM2010 was released March 6th 2010.
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.
- Externalized authentication to a single service (brokered authentication)
- 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 Authentication (AuthN) and Authorization (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.
There will be other posts talking about AuthZ in terms of RBAC via FIM 2010 and ABAC via claims in Windows Identity Foundation (WIF).
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.
ADFS 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. Secure Token Services (STS) aka Issuer 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 to be sure the token was issued by the issuer.
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 whether 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..
Keith Brown (PluralSight) has comprised a clear story about the why Identity Federation is the way of the future… rather than setting up ghost users in your corporate realm that look like users from your partners realm. Just one more thing about that. Allowing external users to your corporate network by setting up accounts for them has great disadvantages of course. It´s another set of credentials for the user to remembe, but most of all… revoking the account may never happing. Your partners, if ever, will tell you much later that this user accounts is revoked. You want to know immediatly. If your partner disables a user on his side, you want that user to be disabled on your side, obviously.
So why fedeating.
It ´s better for users
- Less passwords to remember… not reduced to one identity… just less!
- Better options for privacy/anonymity
Easier for application developers
- Consistent way to get identity details
- IdP does the heavy lifting
Can lead to better security
- Incremental improvements to IdP benefit all apps
Conclusion
FIM2010 is not ADFS… since identity management and user provisioning is not federating identity stores.
Ivo Bouwman 