Cross Organization Single Sign-on made real with ADFS

Artykuł
03/23/2010

One of the biggest challenges an IT Department can face comes when identities need to cross company boundaries. When your organization enters a relationship with another organization and anyone from one sides need access to resources on the other side, you need a way to establish a secure trusted relationship. For Administrators this creates a dilemma, they don’t want to be giving administrative rights to people outside their organization, but at the same time the additional burden of the extra identity management tasks. But you do want to be able to use your current Active Directory environment to provide single sign on. The solution for this scenario is Active Directory Federation Services (AD FS). AD FS has a number of features that allow you to securely share digital identities across enterprise boundaries. Here are some examples of where AD FS can be used.

One way Microsoft has used AD FS internally is for providing access to an internal technical event site. Twice a year Microsoft’s holds a week long training event for all its technical engineers. The event site manages registration, accommodation, agenda building, and downloads, as well as other ancillary activities. The group within Microsoft that organizes this event outsources this site to a partner organization. The site is available year round; employees can access it before, during and after the event. In this scenario AD FS is used to allow employees to log on using their network credentials, there is no need for the event organizers to issue ids and passwords when people register at the event, the web site operates outside Microsoft’s network which makes it accessible to any employee anywhere anytime. Before AD FS, employees had to register an ID and password upfront, onsite registration became more complex as there had to be an administrator on hand to create the IDs. This solution uses the Web Single sign-on feature, Microsoft has established a trust with the event organizers and that enable them to validate log on requests against it’s AD DS environment.

In this example you’ll probably point out that the partner organization is running on Microsoft technologies so the integration is that much easier. However, the solution would work even if that were not the case. AD FS 2.0 supports the WS-Trust, WS-Federation, and Security Assertion Markup Language (SAML) 2.0 protocols. The WS-Federation specification enables environments that do not use the Windows identity model to federate with Windows environments. The event organization and Microsoft could have used federated communications between any Web services–enabled end points to create the solution.

Another example comes from Quest Software. They create and support on-premises systems management products. With this traditional software, single sign on (SSO) was not accessible—customers could not share identity and permissions among Quest solutions, and they had to set up and maintain roles and permissions within each product. Because there was no centralized role management or identity federation, customers could not share data and permissions directly with partners or Quest; when customers needed technical support, they sent log files to Quest IT support staff. Quest Software wanted to enable its customers to share access with their partners and with Quest support staff, to manage user roles centrally, and to log in just once to use multiple Quest services. Using Windows Identity Foundation, Active Directory Federation Services 2.0, and Windows Azure, Quest can provide strong data security, centralized role management, and single sign on and direct access capabilities.

So how does AD FS work? AD FS is based on organizations creating a federation trust between them, in the first example above where two organization wish to share access to a web application hosted on one side, both organizations installed a Federation server in their environment. Like many enterprises role and user information that is necessary to manage and authorize access comes from Active Directory Domain Services (AD DS), in this example however, the request for role and user information is obtained from AD FS instead of direct from Active Directory data for authorization purposes. AD FS in the Microsoft domain controls which roles are sent to the event partner. They in turn have a second AD FS instance in their domain, to establish a federated trust relationship between the two. There are rules set at the event partner side that check that values presented meet with certain restrictions. The end result is that this allows employees to sign onto the event site using their credentials as if the site were any other internal site.

One of the reasons to use AD FS is to reduce the burden on the IT Administrator from managing accounts in their domain for people in another domain they have no control or knowledge of. While AD FS does achieve this, there is still the local management to consider. In the first two posts, we covered how Forefront Identity Manager (FIM) 2010 has the ability manage identities. We talked about how a change made by the HR department in the HR application can be synchronized by FIM to update AD DS. Because AD FS and AD DS are tightly integrated, changes within your environment can be synchronized by FIM in a way that ensures that AD FS is aware of these changes.

As our examples have shown, being able to project identities across boundaries securely can be an advantage in business. Forefront Identity Manager 2010 and Active Directory Federation Services together provide a powerful IAM solution; enabling organizations to reduce help desk calls through self-service identity management and controlled identity sharing.