There is much discussion these days about Active Directory Federation Services 2.0 (ADFS) and the out-of-the-box support of identity and attribute data other than Active Directory (AD). In this blog (part 1 of 2), I plan to cover the basics of extending ADFS using the Microsoft Windows Identity Foundation (WIF) components. In part 2 of 2, I will cover some of the more important questions that should be asked prior to setting out to build your own Identity Provider (IdP) / Security Token Service (STS) or Attribute store vs. purchasing a supported solution from a 3rd party vendor.
Currently ADFS only supports (out-of-the-box), authentication (identity information) and authorization (attribute/claim information), directly from Active Directory (AD). However, what many people are missing is the fact that ADFS does ship with a Framework (WIF) to extend ADFS to meet just about any need you may have for both authentication and authorization.
If your identity information is located in a store other than AD, you can choose to build your own IdP/STS for authentication from the framework provided or purchase one from 3rd party vendor that is formerly supported such as the Optimal IdM Federated Services product. If you are looking to augment the claim information with attribute data that is located in a store other than AD/AD-LDS or SQL, you can choose to build your own Attribute store for authorization which is a pluggable module in ADFS or again, purchase one from a 3rd party vendor. The Optimal IdM Federated Services product also includes a pluggable attribute store module that can surface attribute/claims from many different stores including nearly every LDAP on the market (ADAM, AD-LDS, Sun, Oracle, eDirectory, Open LDAP, OpenDS, etc.) as well as most databases (SQL, Oracle, DB2, etc.).
Writing your own IdP/STS or Attribute store, isn’t extremely difficult, however, you need to first determine what features are most important to your organization prior to setting out to write your own. Here are just some of the features that are included in the Optimal IdM Federated Services product and commonly used by many of Optimal IdM’s customers and should be considered:
- Authenticate users from multiple AD forests without any forest level trusts in place
- Authenticate users from many different backend systems (AD, ADAM, AD-LDS, Sun, Oracle, eDirectory, Open LDAP, OpenDS, etc.)
- Authentication methods such as traditional forms-based, Windows Integrated, client digital certificates, DoD CAC cards, 2-factor (Keep in mind that ADFS only support user/pwd and Windows Integrated Authentication out-of-the-box)
- SSO support for existing IdM systems via header variables or cookie based solutions
- OpenID Integration
- Denial of Service (DoS) prevention
- Proxy capabilities
- Load-Balancing & Failover on front end web and backend data stores
- Assertion Encryption
- Audit logging of assertion and claim/attribute information
- Federated Sign-out
- Change Password & Forgot Password (Self-Service Password Reset)
- Built-in connection pooling and performance optimizations for high-volume usage
- Virtual Attributes & data translations/filtering
- Passive & Active Profile
- Office 365 integration including synchronization of on premise identities to the cloud and federated login with client applications (Lync, SharePoint, Outlook, etc.)
In Part 2 of 2, I will discuss the key questions that should be asked before embarking on the build vs. buy scenario for extending ADFS.