Thoughts on Some of the Key Security Challenges Involving Web Single Sign-on (SSO)

Thursday, May 15, 2008

Most of our customers are familiar with DirectControl's core ability to seamlessly integrate non-Microsoft operating system platforms such as UNIX, Linux and Mac into an Active Directory environment. But over the years we have also heavily investing in building on top of DirectControl's OS-level capabilities some really solid technology that enables Active Directory-based single sign-on to custom web and java application servers running on a UNIX, Linux or Windows systems. Over a series of blog posts I want to discuss the capabilities Centrify offers in the area of Web Single Sign-on (SSO), with the first post being some thoughts on some of the key security challenges we see customers look to address as it relates to Web SSO. This set of blog posts on Web SSO are a complement to our upcoming webinar on Web SSO (which I urge you to register for :-) ) and other resources such as our Web SSO chalk-talk and this earlier blog post on our java/J2EE support.

As we all know, web and Java technologies like J2EE are mature technologies that have been widely used in many organizations for many years. However, custom web applications use many approaches to authenticating and authorizing end-users. Understanding and choosing the right approach can be a confusing and difficult process, often requiring external consulting time and rationalization with existing security policies and architecture. With the standard username and password approach to authentication (which is a very common deployment option with custom web applications), application administrators may find that this approach has some shortcomings when compared to more secure approaches provided by commercial security software:

• Additional usernames and passwords have to be defined and managed in each custom web applications. This creates a hassle both for end-users, who need to remember another username and password, and for IT and web application administrators, who need to deal with password resets and user account lockouts.
• Additional usernames and passwords also create security vulnerability, as end-users often write down their username and password in order to remember them.
• Another security concern arises when end-users leave an organization. Their user account in each application (and in Active Directory, and in every other system and application they are provisioned into) needs to be at least deactivated if not completely deprovisioned.
• Finally, not all custom web application users are for intranet employees alone, so an enterprise solution also needs to address the authentication and authorization of extranet users such as remote employees, customers, suppliers and other partners.

The following slide summarizes these issues and challenges:

Microsoft provides the ability to integrate web applications with Active Directory if the web server is Internet Information Server (IIS) and is installed on Windows Server. This is of little help to the majority of custom web applications administrators who have deployed on a non-Microsoft application server (Apache, Weblogic, Websphere, Tomcat, JBoss) and on a non-Windows platform (AIX, HP-UX, Solaris or a flavor of Linux) platform. Even a non-Microsoft application server deployed on Windows server can be just as difficult to integrate with Active Directory. Alternatives to using basic username and password authentication for custom web servers installed on UNIX or Linux include:

• Complex and expensive PKI infrastructure providing access via SSL and X.509 client certificates.
• Pluggable Authentication Modules ("PAM") to leverage the UNIX operating system credentials. While the PAM approach can be integrated with Active Directory using DirectControl for Systems, this is less than an ideal solution because it challenges end-users to re-enter their Active Directory username and password, depriving them of the SSO login experience.
• Integration with non-Active Directory directory services or databases. This approach creates yet another identity silo that has to be managed and rationalized with users existing Active Directory identity. This is the most common approach when extranet users are involved.
• Limited, but built-in or open source support for Active Directory integration from the application server. Active Directory integration is not a core competency of these options and often are limited to very simple integration with one or two hard-coded domain controllers.

Other higher-end enterprise features such as cross-domain authentication, failover support for NTLM, domain controller failover support, large group-based access control, and access rights reporting are simply not supported with most other approaches.

Other challenges arise when organizations need enterprise-quality end-to-end support. For example, Microsoft will support the Windows client side for SSO and authentication, but does not provide support services for UNIX.

This slide below describes some of the challenges and deficiencies with the built-in AD integration capabilities that you get with various web application servers:

Based on feedback from custom web applications administrators who needed true enterprise-level SSO capabilities for working with Active Directory, Centrify has built a dedicated solution that extends DirectControl to web/Java applications servers. This means intranet users can access their critical business applications without having to enter and re-enter a username or password; instead by leveraging their Active Directory credentials they are immediately provided access with the proper identity and role. Further, extranet users only have to sign on once using a single username and password assigned to them by your applications administrators or even using their Active Directory user credentials through federation.

Some of the key features and benefits of Centrify DirectControl for web/Java that come to mind include:

• Increased user satisfaction and fewer user/password-related support calls by providing users with single sign-on (SSO) access to custom web applications using their Active Directory credentials.
• Increased security by letting IT administrators disable access to not only to Windows but also to DirectControl-managed systems and applications such as custom web applications via a single management tool - Microsoft Active Directory.
• Enforce consistent password and other security policies using familiar Active Directory tools.
• Deploy without intrusive changes to Active Directory.
• Simplify compliance with regulatory requirements.
• Maximize your existing investment in Active Directory.

I think this slide below encapsulates some of the key features mentioned above and how DirectControl addresses the challenges I documented earlier:

In my next blog post I will drill into the architecture of our web and java support in more detail, and then discuss some use case scenarios on how customers are using our web and java/J2EE support.

[Special shout-out to Corey Williams, our Director of Product Management for Applications, on helping me with the content in these web SSO blog posts.]

Bookmarks:

< Previous Article: NIS-Migration.com Is Now Live; New Resource Site for Replacing NIS
> Next Article: A Closer Look at Centrify DirectControl's Web SSO Solution

3-Part Webinar Series What Gartner Says About Using Active Directory for Centralized Authentication, Auditing and SSO

"The combination of Active Directory and Centrify DirectControl gives us a really powerful single authentication solution across a highly mixed environment. Although there are other ways to do this, we've had good success with this solution."

Bill Hilf
General Manager of Platform Strategy
Microsoft
Quoted in Port 25 magazine
March 31, 2006