Web SSO for Extranet Applications using ADFS and DirectControl for Java/Web

Wednesday, May 28, 2008

In my last few blog posts I discussed some of the challenges customers are trying to address with Web single sign-on (SSO) solutions, the architecture and key features of our DirectControl solution for web and Java/J2EE applications, and the specific use case of web SSO for intranet applications (applications where all of the users are "internal" users such as employees, contractors and consultants.) In this final blog post regarding DirectControl for Java/Web I would like to discuss the second use case regarding web SSO for extranet applications using ADFS and DirectControl for Java/Web.

[Don't forget to join us tomorrow for our webinar that goes into much more detail on integrating non-Microsoft web servers with Active Directory.]

For applications that support extranet users that do not exist in Active Directory, the DirectControl for Java/Web solution can be used to integrate with identity stores that are separate from Active Directory. The technical approach that DirectControl uses for web single sign-on is a Microsoft technology called ADFS (Active Directory Federation Services.) ADFS is a freely available set of services in Windows Server 2003 R2 and 2008. ADFS provides two primary functions:

• Routing requests that come in from external users to the appropriate ADFS server for authentication.
• Issuing security tokens to users upon successful authentication.

On the Microsoft IIS platform, a plugin called the ADFS web agent is able to receive and route unauthenticated user requests to ADFS and parse security tokens of authenticated users. The DirectControl for Java/Web agent performs the same functions of the ADFS web agent, but on the non-Microsoft applications servers such as Apache, WebLogic, WebSphere, Tomcat and JBoss. [Note: DirectControl supports Weblogic, Websphere, Tomcat and JBoss running on Windows as well as Linux and UNIX. This same agent also works in an intranet environment leveraging Kerberos and LDAP.]

By leveraging the ADFS services that Windows Server provides, you can provide your extranet users a true single sign-on with a minimal investment in additional middleware and infrastructure.

There are two primary deployment scenarios for single sign-on for extranet applications using ADFS.

• The first is single sign-on from a user directory that resides in the same security domain as the application.
• The second is a deployment that "trusts" another domain to authenticate users and provided a signed token with the "claims" regarding the user.

In the first scenario, you will need to create an account store for users who do not have an account in Active Directory, typically customers, suppliers and other partners. You do have the option of setting up a domain controller with a one-way trust to your primary Active Directory forest; however, this is a bit heavyweight and requires additional infrastructure and administration.

In Windows Server 2003 R2 and 2008, there is a set of freely available services called Active Directory Lightweight Directory Services (AD LDS, formally known as ADAM) and Active Directory Federation Services (ADFS). We will discuss identity federation in the next section, but for now let's concentrate on the SSO use cases where a user is stored in AD LDS. The following diagram depicts this scenario:

Notice the major components:

• DirectControl for Java/Web protecting the non-IIS applications servers.
• An ADFS server to service the extranet users.
• An AD LDS instance to store the extranet users.
• The same ADFS server also services the non-IIS application server running DirectControl for Java/Web.
• An ADFS server to service the intranet users.
• Active Directory to store the intranet users.

The primary steps a user goes through in order to authenticate once and SSO to additional sites is as follows:

1. A user requests a page from a web application that is protected by DirectControl for Java/Web and ADFS.
2. The request is redirected to ADFS to look for an appropriate way to authenticate the user. The user is redirected to a login page requesting the username and password of an account defined in AD LDS.
3. The user is authenticated and a cookie containing the user's SAML token is created and the user is redirected back to the requested application.
4. The application recognizes the trusted user and parses the SAML token to obtain the user's identity and any custom claims (attributes) about the user. The user is granted access with the appropriate role(s) and the application is personalized using the user's own attributes.

The second SSO option is to allow trusted partners and customers to provide their own authentication mechanism. This approach allows a user to be authenticated in one domain to an application that resides in a separate domain. Identity federation generally has a very broad and encompassing meaning. Here we are discussing just the use case where a user is authenticated in one domain to an application in a second domain.

Notice the major components:

• DirectControl for Java/Web protecting the non-IIS applications servers.
• An ADFS account server (and proxy if needed) to service the partner's or customer's users.
• An ADFS server (and proxy if needed) to service the application server(s).
• A federation trust established between the ADFS servers.

The primary steps a user goes through in order to authenticate once and SSO to additional sites is as follows:

1. A user requests a page from a web application that is protected by DirectControl for Java/Web and ADFS. The request is redirected to the ADFS resource server to look for an appropriate way to authenticate the user.
2. The request is redirected to the ADFS account server, which validates the user's existing credentials.
3. The ADFS account server provides a cookie containing the user's WS-Federation SAML token and the request is redirected back to the requested application.
4. The application recognizes the trusted user and parses the SAML token to obtain the user's identity and any custom claims (attributes) about the user. The user is granted access with the appropriate role(s) and the application is personalized using the user's own attributes.

Finally, I believe it is important to understand some of the benefits of using ADFS and DirectControl for Java/Web to provide users with true SSO for extranet applications:

• Users are able to use the most appropriate identity whether it be the intranet users from Active Directory, a user identity assigned to them by you, or their own identity from a separate but trusted federation partner.
• ADFS services are built in to Windows Server and can be deployed and used at a much lower cost that other federation and SSO products.
• DirectControl for Java/Web provides the necessary solution, services and support to leverage ADFS on non-Microsoft applications server such as Apache, WebLogic, WebSphere, Tomcat and JBoss.

And of course DirectControl also addresses Web SSO in an intranet environment as well as addresses SSO at the operating system level, so we give you just one architecture for both OSes and applications (including databases and packaged apps such as SAP). And we do so by leveraging a de facto standard technology you already own and have skill set in - Active Directory. Powerful stuff!!!

I hope that this series on the challenges customers are trying to address with Web single sign-on (SSO) solutions and the solution that Centrify provides to address these challenges have been helpful.

Don't forget to join us tomorrow for more details including demos and customer examples in our webinar on integrating non-Microsoft web servers with Active Directory.

[Special thanks to Corey Williams for assistance on this blog post and providing much of the content.]

Bookmarks:

< Previous Article: Web SSO for Intranet Applications Using SPNEGO and DirectControl for Java/Web
> Next Article: We're hiring!