In the last decade, many large organizations have developed numerous information systems but often times with very little coordination. As a result, information systems can be redundant and cannot interoperate, and data is repetitive and inconsistent (stove-piped information systems). In fact, one of the greatest challenges facing large organizations, such as the US federal government, is the failure of information systems to interoperate and effectively share business-critical data. Although it isn't easy, you can establish a unified enterprise architecture (EA), align projects with that enterprise architecture, and carefully plan and control your investments. I first discuss the enterprise architecture approach to an e-authentication project and then concentrate on some technical considerations.

Page 2 of 3

Align the authentication service project to the enterprise architecture

First, consider how to align the e-authentication project to business objectives within an enterprise architecture. As enterprise architecture is a relatively new topic, let's discuss what an enterprise is and what it involves. According to the US Department of the Treasury's Treasury Enterprise Architecture Framework (TEAF) definition, an enterprise is an organization supporting a defined business scope and mission (see Resources). An enterprise comprises interdependent resources that should coordinate their functions and share information in support of a common mission. Enterprise architecture includes a strategic information asset base, which defines the business, information necessary to operate the business, technologies necessary to support the information systems, and the transitional processes necessary for implementing new technologies in response to changing business needs.

Enterprise architecture involves a top-down, business strategic-driven process that coordinates the development of a business architecture, an information architecture, and a technology architecture that support individual applications as well as the entire enterprise application portfolio. It represents the holistic view of the enterprise's key business, information, application, and technology strategies and their impact on business functions and processes. Since enterprise architecture development itself can be a very lengthy process, I select a small piece of an enterprise architecture closely related to application authentication for further discussion. The table below represents an enterprise architecture from 10,000-foot level. Let's use this as the starting point to talk about unification strategies.

The slice of enterprise architecture for e-authentication

 Business architectureApplication architectureTechnology architecture
As is (baseline)List of business processes; each has its own authentication.List of information systems that support those business processes; different application architectures for authentication.Applications are hosted on different locations, different hardware, different operating systems, and different Web and application servers.
To be (target)List of business processes; all share a common authentication process.All information systems will use the authentication service.Relatively centralized date centers with high capacity of hardware, software, and network systems.

Migration from "as is" to "to be" via service-oriented architecture and model-driven architecture

An enterprise architecture needs a detailed sequencing plan to evolve the baseline architecture to the target architecture. The plan's major elements include program/business improvement IT projects and major infrastructure and technology upgrades. The IT projects include the e-authentication project and all other projects that use the e-authentication service. The best strategy for migration involves service-oriented architecture (SOA): e-authentication will provide authentication service to all other applications that require authentication. The goal is to build a service that offers value and creates standard profiles in the enterprise architecture repository to avoid redundant development efforts.

What is SOA? It is a way of designing a software system to provide services to either end-user applications or other services through published and discoverable interfaces. In many cases, services offer a better way to expose discrete business functions, and therefore, an excellent way to develop applications that support business processes. In my opinion, SOA differs from component-based architecture (CBA). SOA is CBA, but the reverse is not necessarily true. Let's use Web services and Enterprise JavaBeans (EJB) as an example. Web services is obviously an SOA. The EJB model is a CBA, but it may or may not be an SOA depending on how the EJB components are deployed. For example, if one vendor develops and sells the user management components to many customers, this model could be considered a CBA. In that case, all the customers should consider application architecture issues such as how the EJB components will be deployed and technology architecture issues like the necessary hardware and software to support EJB deployment. If a company uses SOA, the user management EJB components and related databases will be centrally hosted and made accessible enterprisewide. Only EJB clients—the calling stubs—will be distributed to projects that need to access user management functionality.

SOA requires well-defined interfaces. And this in turn requires a model-driven architecture (MDA). The most important ideas behind the Object Management Group (OMG)'s MDA are the concepts of the platform-independent model (PIM) and the platform-specific model (PSM). PIM is independent of any actual implementation details, while PSM can be converted into language code designed for a specific platform. If you read my article "Step Into the J2EE Architecture and Process," you perhaps will notice that PIM and PSM resemble the object-oriented analysis and design concepts I proposed about two years ago. MDA raises the level of abstraction and helps to unify the enterprise by maximizing reuse and promoting information sharing across different technology stacks like Java 2 Platform, Enterprise Edition (J2EE) and .Net. Figure 1 shows the MDA development process.

Figure 1. An MDA development process (Source: Meta Group and the OMG, 2002)

Value propositions beyond an enterprise

A well-designed e-authentication service can service applications beyond those you list in your enterprise architecture. If your project is successful, other interested organizations can reuse your service. You might even become an authentication service provider. On the other hand, if you cannot make it work, somebody else will. In that case, you might become the customer of someone else's authentication service.

Fund and manage interdependent projects

Even if you have the world's greatest idea, you will not achieve much success without an IT project that is properly funded, managed, and delivered. Well-coordinated IT projects drive the move from "as is" to "to be" architectures. Depending on your ambitions, an e-authentication project could cost from thousands to millions of dollars. Most complex organizations conduct some form of business strategic planning, often coordinated through a strategy committee or planning organization that identifies threats and opportunities and recommends appropriate organization responses and investments. For the federal government sector, this process is called capital planning and investment control (CPIC). These recommendations become part of the company's plans and budgets. Figure 2 shows how projects are established in an enterprise.

Figure 2. Interactions between enterprise architecture, CPIC, and project management (Source: Department of Veterans Affairs, 2001)

Someone must convince decision makers that your e-authentication project aligns well with the enterprise architecture and its value proposition is well worth the capital investment. It's equally important that all other projects that require authentication be carefully evaluated to avoid the development of their own stove-piped authentication modules. As we move from stove-piped projects to a unified enterprise architecture, complex dependencies among projects will arise. Depending on the SSO project's scope, it might take a few months or several years to develop in parallel all projects dependent on the SSO project for authentication and/or authorization. Clear interfaces must be well defined so that each project can efficiently proceed.

Complications can of course creep in. Your authentication project might not have enough financial and management support. Or you might decide to branch off your project to develop a generic SSO solution. For the Department of Energy, I was the technical lead and architect for multiple projects, and they all required authentication and some common functionality. Our team developed the SSO solution as well as many other projects that also required authentication service.

The E-Grants project, one of 24 e-government initiatives, provides a good example for interproject dependency analysis. The US federal government awards more than 00 billion in grants each year to state, local, and tribal governments, universities, and nonprofit organizations. These grants are managed and awarded through 26 major "grant-making" agencies in more than 500 programs. The E-Grants initiative allows potential grantees to apply for all types of grants online through a unified Website, which obviously requires user authentication and authorization. Figure 3 shows a high-level diagram for user authentication.

Figure 3. The E-Grants project user authentication diagram (Source: E-Grants, 2002)

The e-Authentication project is another e-government initiative intended to provide authentication service to the 24 e-government initiatives and eliminate the need for each initiative to develop a redundant solution. The e-Authentication project is scheduled to go into full production in October 2003; whether it will go live on time and actually provide satifactory service to the E-Grants project is still up in the air. To mitigate this risk, the E-Grants project plans to initially use its own username/password-based authentication but will be prepared to use e-Authentication when it's ready.

Type of applications to support

Another important factor to consider in your e-authentication project is what type of applications you expect to support. Typical applications include HTML-based Web applications (JavaServer Pages (JSP), Active Server Pages (ASP)), applet-based applications, Web services, and wireless applications. The applications we discussed in my last article are mostly J2EE or ASP HTML-based applications. But your customers might demand that you also support applet-based or even client/server-based applications. Should you just ignore this business opportunity? Or should you adapt your solution to win new customers? Or even better, should you have a well-constructed solution that expects this kind of situation?

Oracle's e-business applications offer a good example. Oracle's E-Business Suite consists of dozens of applications. An applet is used at the infrastructure level so that legacy Oracle forms applications can deploy as Web-based instead of client/server-based applications. What a sleek idea! Oracle developed an applet and a huge number of Oracle forms applications that can now be upgraded to Web-based applications without a major rewrite. Given that you have no source code or even documentation about how this Oracle applet works, don't you think it's quite a challenge for your SSO service to support this scenario? Plus, you would need serious financial backing. A few weeks ago, I learned that one government agency has committed to migrate its stove-piped projects to Oracle Financials, and it is a 00 million, six-year project.

If things seem difficult already, think about supporting Web services, wireless devices, and other types of clients. As most enterprise information portals support some sort of SSO, you need to decide whether you should expand your e-authentication to cover portals or just use the commercial off-the-shelf (COTS) SSO provided as the baseline and then expand.

Levels of authentication

One of e-authentication's key objectives is to establish trust, and trust exists at different levels. The ability to provide a range of authentication services is valuable. Password authentication might be sufficient for many business scenarios such as online shopping, but additional security may be required for other scenarios. A public key infrastructure (PKI)-based solution can offer many different levels of identity assurance. At the first level, the user presents some unique personal information such as address and social security number to verify his identity on the Internet to get an instant certificate. At the next level, a user may be required to show up in person with identification like a driver license. A minimum background check or even a security clearance may be required to issue a certificate with very high-level security. Smart cards combined with PKI are quite promising. Biometrics authentication (face recognition, finger printing, or iris scanning) can also come into play. An authentication service with potential to become the de facto standard will need comprehensive coverage of multilevel authentication.

Identity propagation

In my previous JavaWorld article, I mentioned that a token could be placed in a user's session to identify whether a user is authenticated. But when we introduced EJB as reusable components for multiple applications, we initially had problems propagating a user's identity because the EJB components were hosted in a remote container. You could use a generic user to log into the EJB server to make remote calls on behalf of each user, but this defeats the purpose of a fine-tuned EJB security model. Figure 4 shows the E-Grants n-tier application architecture. Do you see any possible identity propagation issues assuming the E-Grants project will use some type of e-authentication service such as PKI-based authentication or Microsoft's Passport?

Figure 4. The E-Grants n-tier application architecture (Source: E-Grants, 2002)

Identity propagation is always an issue for n-tier distributed applications. For component and information sharing, an independent application tier is often introduced to host business logic. For example, the business objects shown in Figure 4 might be enterprisewide, reusable components shared by many different applications; thus, they are very likely hosted on a remote application server. Making a call to an EJB method in a remote container will require a user's identity and credentials. Forwarding a cookie or token will do you no good if the EJB container does not understand it. Many popular application servers support plug-and-play, customized authentication specific to each vendor. We were lucky that our EJB container supported modular authentication, so we developed a customized authentication module that recognized a Kerberos ticket-like token the gatekeeper obtained from the SSO server. You will be lucky if your EJB container's authentication functionality is modular and can be easily customized.

Sometimes identity and credentials are required for the back end. For example, Oracle forms use a user's database account to log in to the applet and then need credentials to log in to the backend database. It might be difficult for the Oracle relational database management system (RDBMS) to understand your cookies or tokens.

Any solution using point-to-point authentication will have this issue. Again, PKI-based authentication provides a good example. Some vendors' implementations tend to store and send a user's password to partner applications. This of course has severe security implications in an SSO environment.

Value add-ons

You could extend the authentication service's scope with value add-ons. Let's consider user authorization. In the solution we developed at the US Department of Energy (DOE), as each user logs in to the system, we added employee and organization information to each user's session with well-defined interfaces. As information about employees and organizations are centrally hosted and managed in the enterprise, infrastructure such as hardware, operating system, application server, and EJB components are all shared by supported applications. We also added support for authority delegation.

Another possible value add-on is e-signature. As required by law, many business-critical transactions need signatures. An e-signature can authenticate a message sender's or a document signer's identity, and possibly ensure that the message's or document's original content has been sent unchanged. The Electronic Signatures in Global and National Commerce Act (often referred to as the e-signature bill) specifies that in the US, the use of a digital signature is as legally valid as a traditional signature written in ink on paper. However, not many Web-based information systems can support this feature.

Most Web-based systems tell you to add your signature by clicking a button or ask you again for your password even after they know you have successfully authenticated to the system with your password. After you "sign" the transaction, a flag in the database usually changes from false to true. These transactions should not be considered legally bound signatures. A few months ago, DOE Secretary Spencer Abraham demonstrated a real e-signature tool at a ceremony by stamping his personal e-signature on the department's e-Government Stratgic Action Plan and presented the plan to the Office of Management and Budget (OMB) Director Mitch Daniels. The DOE has procured and licensed this PKI-based digital signature technology for governmentwide use. However, currently, this technology only supports PDF documents. It will be very interesting to see how this technology can be extended so that users can apply e-signatures for e-transactions in Web applications. This will provide tremendous value to any business-critical application.

Avoid single point of failure

Developing an authentication system for each project is too much, while developing one single authentication system for the whole universe is too ambitious and risky. You should figure out the right balance for your own situation. Any SSO system without appropriate compartmentalization is a single point of failure and carries great risk. Specific factors to consider include: whether your Internet and intranet applications should be separated, and whether application authentication, operating systems authentication, and network authentication should be integrated or separated. If security is a major concern, you should give a user the minimum permission to do his work—nothing more, nothing less. For example, if a user only needs access to a Web application, you don't need to create an operating system account or database account for him unless you have a good reason.

Another factor to consider is reliability and serviceability. Imagine if thousands of applications depend on your authentication service, but your system is unavailable or you must restart your operating system every weekend. The more business you develop, the more liability you acquire. Because of the large scale of users, applications, functions, transactions, and other components of this system, technology architecture must be carefully studied. Service-level agreements (SLA) should be introduced, and the technology architecture should be well defined and structured. For example, if your SLA specifies your annual downtime cannot exceed 10 minutes, and authentication response time cannot exceed 2 seconds for 5,000 concurrent users, certain types of technology architectures might be better than others. It might be impossible for many types of hardware and software to ever achieve this kind of performance. IBM mainframes and high-end Unix boxes are more expensive, but can usually provide better reliability than Windows and Intel-based solutions.

Forward compatibility

As business consolidation continues, your SSO or even your organization might merge into a larger force. If you are in the private sector, your company might get bought. If you are in the public sector, the OMB is trying to develop an e-authentication service across all federal government agencies and possibly extend it to the private sector. So you can either wait for the "big bang" or develop your own authentication solution but keep in mind that some day your solution might be replaced by the federal e-authentication implementation. Forward compatibility is an important consideration when you design a system that requires authentication. It's interesting and educating to watch how the E-Grants project handles its authentication, especially with a federal e-authentication project working in parallel. Figure 3 showed the E-Grants authentication architecture, but the following excerpt from the E-Grants project's architecture overview provides more information (see the E-Grants URL in Resources):

While the E-Grants systems may use initially an enhanced system of usernames and passwords as the initial user authentication mechanism, it is planned that the E-Grants initiative will eventually leverage other federal projects to provide public key infrastructure (PKI) authentication mechanisms. Particular care has been made in the design of the E-Grants systems to provide a clear upgrade path to PKI. In addition, the E-Grants project team will work closely with the e-Authentication team to ensure that E-Grants solutions are compatible and compliant with overall e-gov requirements and capabilities.

Avoid starting from scratch

I have talked a lot about how to develop an e-authentication service in-house. However, this doesn't mean I prefer building an in-house solution to buying a COTS product. The advantages of buy versus build in many situations are obvious. If you decide to use a COTS product, there are at least three versions. First, SSO is provided natively in Windows 2000 by the built-in Kerberos and Secure Sockets Layer (SSL) protocols. Second, some COTS products just support SSO like Netegrity's SiteMinder. Third, many portal software packages support SSO as a value add-on to their core products. After you narrow your decision down to one of these categories, you should carefully evaluate all candidates' features. After reading this article, you can compare the list of considerations discussed here with a product's particular offerings—out of the box or via customization. In most situations, no product will satisfy all your requirements. It's impossible for any vendor to develop a one-size-fits-all solution that foresees and satisfies every existing and future customer need. You need to exam how easy it will be to customize and extend a core COTS product.

Business models change rapidly as technologies advance. A recent trend is SOA. With service-level agreements, customers no longer buy copies of software. Instead, they buy Web services just like utilities. Many organizations no longer have their own data centers. On the other hand, software developers no longer just sell versions of software. They develop software and host the services. If you decide to buy authentication services from others, you need to think hard about whether the service offered follows public standards. If the technology is proprietary, it will be difficult to integrate. Second, you might get locked into a single vendor. Once authentication for all your information systems is locked into one vendor, you will have very little bargaining power.

I would like to thank Venkatapathi (PV) Puvvada, chair of the Industry Advisory Council (IAC) Enterprise Architecture Committee, for reviewing this article. I would also like to thank Richard Soley, chairman of the Object Management Group, for giving me permission to use his MDA diagram.

Figure 1 is from "Aligning Enterprise Architecture and IT Investments with Corporate Goals," at, Copyright 2002, META Group, Inc. and the Object Management Group. Figure 2 is from the Department of Veterans Affairs enterprise architecture document (see Resources below). Figures 3 and 4 are from the E-Grants project's architecture overview (also in Resources). All figures are publicly available and used with permission.

Jian Zhong has been actively involved in architecture development for the last five years. He started programming Java in early 1996 and has been a Sun Certified Architect for the Java 2 Platform since October 1999, a Sun Certified Enterprise Architect for J2EE since November 2000, and an IBM certified developer for XML-related technologies since February 2001. Currently, he is a senior enterprise architect in the architecture group at Unisys.
Page 3 of 3

Learn more about this topic