In the organized chaos of e-business support systems, enterprise access management (EAM) vendors say they offer the "Holy Grail" of security: a single sign-on (SSO) solution that authenticates users to your Web portal and authorizes access to critical back-end applications.
But your quest doesn't end when you purchase an EAM solution. There is no miracle in that box.
The benefits of EAM are clear. Market-leading products from Netegrity, RSA Security, IBM/Tivoli and others provide critical security and management functions including role-based access control, content personalization, user self-registration and hooks into other security products, such as firewalls, provisioning systems and IDSes. Many EAM solutions can handle multiple authentication options (e.g., user ID/passwords, digital certificates, authentication tokens) and several types of user repositories (LDAP, RACF, NT, etc.). These solutions also offer auditing services and intuitive Web-based interfaces for user and resource management. In short, you can make a compelling business case for EAM, and thousands of organizations are rolling out these solutions today.
Despite these and other benefits, making EAM software work in a heterogeneous enterprise is a complex challenge. Whether your organization is a bank, a health care provider, an insurance agency or another business enterprise, unanticipated issues are almost sure to impact rollout. Getting the most bang for your buck requires significant up-front architectural planning and design, infrastructure investments, process reengineering, training and a change leadership strategy. The bottom line is that implementation is neither as simple nor as easy as some vendors would have you believe.
The Benefits: What EAM Can Do
EAM products can bring order to what is often a chaotic Web-based enterprise system. Understanding the core capabilities of these products will help you match your business requirements to the right solution and make the case for purchase.
1. Single sign-on can be achieved across Web-based applications. SSO has been an elusive goal for security practitioners since the advent of client/server computing. Prior to the Internet, a number of products -- typically based on complex scripting languages-attempted to address SSO for mainframe, midrange and client-server environments. Behind the scenes, these products were actually storing the user IDs and passwords of each user for each application that they needed to access. In complex IT environments, implementation was difficult and administration onerous.
EAM products address this issue in different ways. Netegrity's SiteMinder 4.6 and RSA's ClearTrust SecureControl 4.6.1 (formerly owned by Securant Technologies) provide SSO across Web applications residing on different Web servers -- within the same domain only -- using a secure, nonpersistent, encrypted cookie on the client interface. Assuming that each of the Web servers is protected by an agent, the cookie is presented to each application that the user wants to access.
IBM/Tivoli's Policy Director 3.7.1 takes a different approach. A secure credential is built for the user on Policy Director's WebSeal, a reverse proxy that sits in front of the Web server. The credential is presented each time a user attempts to access Policy Director-protected Web applications.
Each of these three vendors is planning on supporting both the cookie- and proxy-based SSO methods in upcoming releases.
2. Authorization logic can be abstracted out of the applications. EAM solutions provide basic centralized authorization to give users access to multiple Web-based applications. For example, Tivoli's Policy Director provides an "entitlement" service that will dynamically build a list of all applications that a user is "authorized" to access.
The entitlement page is built once the user has been authenticated by Policy Director. Policy Director may protect dozens of applications, but the user will only see links to the applications that he is "entitled" to access.
SecureControl 4.6.1 has a particularly interesting feature for authorization called "Smart Rules," which provide "dynamic permissioning." This means SecureControl can change a user's authorizations at runtime based on variable data, such as current credit balance.
3. Content can be personalized. EAM-based content personalization can change the access interface or system actions based on user information. For example, when a user attempts to access a Web application, additional information (attributes) can be passed to deliver a personalized response. For instance, if User A belongs to the Senior Payroll Analyst group, his HTML page will display four buttons for four different types of payroll transactions to be executed. If User B belongs to the Junior Payroll Analyst group, he will see only two buttons.
Developers can code the application to make use of this capability. One state health care agency, for example, made this a fundamental requirement for Web-based access to three key applications for customers and employees.
In order to extend this functionality, many EAM vendors are working on developing hooks into standard portal applications such as Epicentric, PlumTree, BroadVision, Vignette and ATG. Netegrity recently acquired DataChannel, a portal vendor.
4. Administration functions can be delegated. One of the most valuable features of EAM solutions is the ability to delegate security administration. This is particularly valuable when you want to delegate authority for a hosted application to a business partner.
The leading EAM solutions all have robust delegated administration capabilities. RSA's ClearTrust Secure Control excels in this, and Netegrity has significantly improved this function in Delegated Management Services 2.0.
The potential cost savings could be significant depending on how many business partners would otherwise be centrally administered.
Caveats: What EAMs Can't Do
Though EAM solutions have impressive capabilities, they also have limitations. Knowing these shortcomings will help you set realistic expectations, make smart purchasing decisions and plan for integration.
1. It's not plug-and-play. Some EAM vendors boast about how quickly their product can be up and running out of the box. In one case, a vendor claimed that they could do it in under a day at the client's site. What the vendor didn't say was that meant a stand-alone NT server connected to no applications, with only a couple of test users.
The reality is that much planning, architecture and design is needed to implement any of the EAM solutions in a complex environment:
- Current business flow and roles must be adapted to the new paradigm.
- The application development plan must be thoroughly integrated with the EAM requirements.
- Missing or inadequate functionality may require "workarounds" or additional customization. For example, SecureControl doesn't natively support LDAP.
Even "simple" implementations will face issues that impact the project. For example, one insurance company required Web-based authentication to a single application only, without complex levels of authorization. Nevertheless, the firm still had plenty of complex integration issues to deal with.
2. EAM doesn't deliver complex authorizations out of the box. No EAM product addresses complex authorization logic without customization. The degree of custom authorization code depends on the EAM solution and the complexity of your application. Often, custom code in the application will be needed to invoke the authorization engine through the vendor API, which could require a significant amount of development.
3.Cross-domain interoperability is a problem. One of the biggest gaps in the EAM space is the inability to pass security credentials between different EAM/custom Web security solutions. In a likely scenario, a customer logs on to your Web portal, protected by EAM Solution A, to conduct a transaction. But information needed to complete the transaction must be obtained from a business partner's site, protected by EAM Solution B. When the customer clicks your business partner's link within your portal, he will most likely be required to re-authenticate, since the security credential generated by one product isn't recognized by the other.
An XML-based protocol, SAML, is being developed to address this issue (more on this later).
People and Processes Count
Perhaps the biggest obstacle to EAM deployment is underestimating the scope of the project.
EAM solutions impact three critical parts of any business: people, process and technology. Typically, the technology gets most of the attention and the people and processes are given short shrift. If that happens, the project will falter, and the results won't approach the goals for the implementation, at least not without a lot of extra time, money and aggravation. Focusing on three critical areas before implementation begins will help assure success:
- Administration. Depending on current system administration processes, the EAM solution may introduce significant change. If a company currently administers users centrally, for instance, delegated administrative services will represent a sea change in how users and roles are provisioned.
- Roles. All EAM solutions have different methods of implementing roles. Understanding those roles will help determine the number and type of roles that must be administered. Where possible, defining enterprise-level roles that are universally understood across e-business applications will maximize the power of EAM.
- Business processes. Creating an authorization logic that spans a heterogeneous enterprise requires a thorough understanding of how business flows through the organization. This is best done through use cases. In simple terms, this means sitting down with users representing various business roles and documenting workflow.
Deploying EAM involves everyone from systems managers and developers to end users. A change leadership strategy should include a communications plan, a training plan and a stakeholder analysis. Everyone in the organization should understand their roles and responsibilities and receive appropriate training.
Learned in the Trenches: Making EAM Work
There are several basic steps that lay the foundation for a smooth and successful EAM deployment.
1. Invest time in architectural analysis and design. EAM implementation can have a profound effect on current and future IT architectures. Understanding how EAM will be integrated will mean getting it right the first time. Key architectural elements to consider include:
- Legacy data integrity
- Data relationships
- LDAP schema and namespace design
- High-availability computing
- Middleware components
- Back-end security systems integration, such as RACF
Assuming you are integrating multiple applications, you'll want your LDAP schema to be complete on the first pass. Analyzing applications that will come under the EAM umbrella will reveal common data elements that determine authorization decisions. Such a data element may be a user role that means the same exact thing to multiple applications (e.g., "claims adjuster"). The results of this analysis will be direct inputs into the schema design for the EAM product's user repository (e.g., LDAP).
Without this analysis, the schema design will most likely be tightly coupled with the first application integrated with the EAM product. When the second and third applications are on deck for deployment, the schema will have to be modified to accommodate those applications' authentication and authorization requirements. That, in turn, could require recoding the first application. The result is delay, and a lot of extra time and money.
2. Expect bugs. Fastest to market wins. Software vendors ramp up their development cycle to beat the competition to market. Quality assurance suffers, and the result is often software bugs.
It's reasonable to expect to encounter bugs and plan for them in an EAM implementation. Vendors conduct much of their testing in greenfield environments. Even with strong testing and QA, vendors will never be able to find every bug simply because of the diversity and complexity of the IT environments in which their products are deployed.
The project plan should allow sufficient time for unit and string testing the solution. The string testing of the EAM solution should be linked to the application's string testing, and thus coordinated with the application deployment team.
3. Double estimates for development efforts. Much of the excitement surrounding EAM is the promise that authorization logic can be abstracted from applications and deployed within the EAM solution. In theory, this would save on development effort, since reusable authorization logic could be invoked by any application that needed it. But EAM products aren't yet at this stage. Plan on a lot of development time.
The most effective way to determine how much development effort is required is to gather all of the functional authentication and authorization requirements for the applications to be integrated. Combined with use cases describing how the application will work, the functional security requirements should provide a good estimate of the development time, including custom security coding. As a rule of thumb, double that estimate. It's not unusual for complex EAM rollouts to take several months from purchase to initial launch.
4. Create standard interfaces. Many EAM solutions provide security APIs to enable applications to invoke security functionality beyond what you get out of the box. But these aren't standard APIs, so plan on a learning curve for developers. More importantly, the application itself will be bound to that API, so the application code must be rewritten if one EAM solution is replaced with another, or if the application/platform is upgraded to a new release.
Creating an application isolation layer via standard interfaces will reduce the need for costly and time-consuming re-engineering by shielding applications from vendor-specific code.
Looking ahead, an extension to the Java security model called Java Authentication and Authorization Service (JAAS) addresses this issue.
5. Build security from the bottom up. Many organizations don't get the full benefit of EAM because there isn't a well-defined design for the security process that exploits the full range of EAM authorization functionality. Or, sometimes the security design isn't integrated with the application development team's systems development life cycle (SDLC).
In either case, the development team will be hard-pressed to go back and redesign its application if and when security requirements are introduced. Changing requirements for a Web-based cash management application, for example, hindered integration at a major banking institution. The result is delay or, worse, a deployment that only takes advantage of the product's basic authentication features.
Contrast this with a success story-a site in which the security process was integrated into the development team's SDLC from the earliest stages of development planning. This "security-aware" SDLC was accessible to the organization's development community via their intranet. At each phase of the SDLC, the EAM implementation team guided the developers through the relevant security process points. The result was a robust EAM implementation, unimpeded by changing requirements.
Where Is EAM Technology Headed?
As EAM solutions evolve, expect important new features, functionality and integration with complementary security technologies.
Interoperability among EAM products is a problem in search of a solution. It's critical to establish a way to jump from a host Web site to a business partner's Web site without having to re-authenticate. EAM vendors such as Oblix, IBM/Tivoli, Netegrity, RSA Security, Entrust and Entegrity are working on an XML solution for the exchange of authentication and authorization information among EAM products.
The protocol, noted above, is called Security Assertion Markup Language (SAML), and is being sponsored by the Organization for the Advancement of Structured Information Standards (OASIS). SAML defines a common language for describing authentication and authorization "assertions." Last fall, Netegrity released a Java-based SAML developer toolkit called JSAML.
As mentioned above, Java Authentication and Authorization Service (JAAS) enables developers to implement authentication and access control functionality while minimizing vendor-specific coding within the application. This will allow customers to switch EAM vendors and/or upgrade their applications or platforms without extensive recoding. Leading EAM vendors such as IBM/Tivoli and Netegrity already provide support for JAAS.
Application server authentication and authorization will be employed by EAM products to provide granular access control out of the box. Many high-end application servers -- such as BEA's WebLogic Enterprise edition and iPlanet's Application Server Enterprise Edition -- provide their own native authentication and authorization security mechanisms. However, these mechanisms can only be leveraged by the applications written on the application server platform. Thus, other platforms, such as client/server and legacy systems, would still need to be secured and managed by yet another security solution.
When an application server's security system is integrated with an EAM vendor's solution, the result is one centrally managed, policy-based security solution that allows security policy to be applied and managed across Web-based, client/server and legacy applications. Examples of this kind of integration are between IBM/Tivoli's Policy Director with IBM's WebSphere, Entegrity's AssureAccess and RSA's ClearTrust SecureControl's with BEA's WebLogic application server, and Oblix's NetPoint with iPlanet's application server.
Other EAM enhancements on the horizon include:
- Greater support for vendor LDAP solutions.
- Integration between EAM solutions and complementary security solutions such as resource provisioning (e.g., Business Layers, Access360, BMC) solutions and intrusion detection solutions (e.g., ISS Real Secure, Tivoli Risk Manager).
- Increased functionality for delegated administration and password management.
These global enhancements, coupled with the evolution of specific product features, bolster the case for EAM. With the right amount of intelligence and effort, EAM becomes a viable security solution for today's e-business, with the promise of better things to come.
Goliaths Vie for 'Net SSO Supremacy
Microsoft and Sun Microsystems are pumping rival plans for global SSO authentication to prime commerce on the Internet. Consumer and business users would have a single profile that would grant access to services across the 'Net, using any platform.
Microsoft's Passport, part of its .NET My Services initiative, already has a foundation of 165 million accounts, amassed largely from automatic registrations signing up for Hotmail and Instant Messaging. The company's latest OS, Windows XP, continually prompts users to register for this service.
Sun's Liberty Alliance, announced in October, started with 50 companies, including Bank of America, GM and United Airlines. The Alliance would allow a user to sign up at a secure interface and access customized information services.
AOL Time Warner, the third player in the arena, hopes to leverage its 31 million subscribers to make its Magic Carpet the standard.
Health care case study: The personal touch
RSA's SecureControl makes delegated administration a no-brainer.
Health care providers are particularly sensitive to security because of federally mandated protection of patient information under the Health Insurance Portability and Accountability Act (HIPAA). Transmitting sensitive medical data across the Internet, intranets and extranets leaves no margin for error.
A state government chose RSA Security's ClearTrust SecureControl 4.6.1 because it delivers on EAM's value in providing delegated administration and personalization. When the job was done, both patients and internal users had secure, single sign-on access to applications of three state-run health care providers through a Web portal. Authorization and personalization for all three applications was managed via dynamic, customized JSP Web pages.
Delegated administration is a major strength of SecureControl. Its module provides an easy-to-use Web interface to create users quickly. This function can be delegated to other administrators within an organization or at a business partner site, which relieves the burden of routine functions from central administration and can reduce costs substantially over time. The robustness and flexibility of the Delegated Administration module have earned high marks in the industry, making it a good match for this agency.
Using the SecureControl JDK library, the agency added a custom-built delegated administration Web interface to its standard user interface. SecureControl's delegated administration provided procedures that conformed to agency security policy.
There was an issue with personalization, however. The agency's Web page personalization displays the user's full name and dynamically filters links, so the user sees only what he's authorized to access. SecureControl's Runtime API was used to filter the links, but couldn't pull basic user information, such as first and last name, from its LDAP user repository. The agency used SecureControl's Admin API to complete the task, which made the JSP pages heavier, since it was making calls to both objects. Also, the Admin API is used to effect critical changes to user data, and employing it in this context made the pages more sensitive.
The agency's user store was another major issue, since Secure Control doesn't have native support for LDAP v3-compliant directories. Secure Control provides for data synchronization between Oracle and LDAP, so the solution user information was replicated in an Oracle database. However, this made managing and manipulating data attributes difficult. RSA plans native LDAP v3 support in its next release to address this problem.
Case study: Insuring success
Insurance company's "simple" Policy Director implementation shows the need to expect the unexpected.
There's no such thing as a simple EAM implementation. There's no such thing as plug-and-play.
The installation of IBM/Tivoli's Policy Director 3.7.1 at a major insurance company was about as straightforward as an EAM deployment can get: get Policy Director up and running with one e-business application within nine weeks. Still, there were significant obstacles to deployment. The implementation team met the deadline -- but not without some pain -- and eventually integrated additional applications.
As with many EAM deployments, the insurance company was a "traditional" business that wanted to expand its e-business component. To do so, it needed to simplify access and authorization -- securely. The company started with what was, in effect, a pilot project for Policy Director. The firm required authentication to a Web-based version of a mainframe quoting application used by customer services representatives and insurance agents to process automobile insurance quotes. The security integration for the e-business application was fairly simple, using only the most basic EAM capabilities. Policy Director only authenticated the user against the LDAP, while the Java servlet that handled security continued to check if the user was authorized to see the quote.
Since Policy Director is a reverse proxy product -- compared to the agent-based SiteMinder and SecureControl -- it doesn't matter what type of Web server is being protected. That's a big plus for potential users concerned about support for existing platforms. In this case, since both the Web and application servers were also IBM products, the point may be moot, but it opens a clear path to bring in other products.
Out of the box, Policy Director provides an authentication layer for applications, with its WebSeal sitting in front of the Web server. Ironically, in an end-to-end IBM environment, the first issue arose when the junction between the WebSeal and IBM WebSphere application server was created. The company was unable to create a connection between the browser and the quoting application on the application server. This turned out to be a mapping issue resulting from an undocumented configuration detail. Updating WebSphere's Virtual Host mapping tables solved the problem.
Core dumps on one of the WebSeals brought the system down and cut connections to protected back-end resources on two occasions. Redundant WebSeals, along with frequent monitoring, mitigated the problem. IBM/Tivoli says it addresses the issue in its new release, Policy Director 3.8.
Policy Director did a poor job of allowing user attributes to be added to provide granular access control, but has also addressed this in v3.8. Policy Director automatically provided two variables, IV-User and IV-Groups (user and group/role IDs), which were passed as HTTP headers to the back-end application. Policy Director recognized only user ID, password and a few other attributes within the LDAP.
SiteMinder and SecureControl provide out-of-the-box ability to define custom user attributes for authentication and authorization.
Financial institution cashes in on Netegrity's SiteMinder.
Financial institutions are prime candidates for EAM deployment. Complex levels of authorization are required for internal employees and customers dealing with everything from checking accounts to multi-million dollar business loans.
The financial institution for this case study is an older organization that has grown slowly into e-commerce as a way to enhance more traditional methods of doing business. The bank wanted to deploy a Web-based application to allow individual and corporate customers to access new repositories as well as legacy systems.
Specifically, the bank wanted to develop a Web-based version of a cash management application on a WebSphere application server. The firm chose Netegrity's SiteMinder 4.5 to provide single sign-on access and authorization.
When rolling out SiteMinder, the bank learned some valuable lessons the hard way. EAM security should always be integrated as part of the development plan before coding begins. In the bank's case, numerous changes in functional requirements for the cash management application -- a form of "project creep" -- slowed the SiteMinder integration. Application development, particularly custom coding to authorize user requests through the EAM API, was inextricably bound to the integration. Changes in requirements had a cascading impact on implementation.
Difficulties with the configuration and maintenance of the WebSphere server, used for development of the application integration code, caused the most significant integration issues. Documentation was poor and configuration clumsy.
The SiteMinder agent for IBM HTTP servers was custom built for this project (support for IBM HTTP is included in the current version, SiteMinder 4.6). SiteMinder provides plug-ins on Web servers to provide URI-level security and application server agents (ASA) to protect resources, such as servlets or Enterprise Java Beans. The plug-in/ASA intercepts calls from a browser, and the SiteMinder Policy Server checks the database to see if the requested resource is protected. If it is, the Policy Server first authenticates the user, then checks if the user is authorized to access the resource.
Several issues with SiteMinder itself highlighted the uniqueness and complexity of the deployment-and the need to plan accordingly:
- Policy Server was installed on Solaris at the client's request, but the SiteMinder report server was only available for NT. A single instance of the SiteMinder Policy Server on NT was installed for reporting purposes only.
- The SiteMinder Administration interface was only compatible with IIS or Netscape Web servers, which had to be installed on the same machine as the Policy Server. Again, the client's standard IBM HTTP server could not be used. A single instance of Netscape Web Server was installed for SiteMinder administration only.
- SiteMinder Self-Registration and Delegated Management Services did not function with the client's Oracle user store, as Netegrity developed these services for use with LDAP directories only. The integration team developed a self-registration component. One of SiteMinder's major strengths is enabling users to self-register. This means extranet users (e.g., business partners or customers) can create their own users IDs and passwords, a potential huge savings in administrative overhead over time.
About the author:
Russell L. Jones, CISSP, is a senior manager with Deloitte & Touche's Secure E-Business consulting practice.