Evaluating Applications

Identity management services are generally provided as a centralized IT function with corporate and business unit applications forming the extended system. Upkeep of this system hierarchy involves a core IT group that manages and maintains the server infrastructure and a satellite group of employees to maintain the LOB applications.

As large organizations often have hundreds (or even thousands) of deployed internal applications, evaluating all of them would be time-intensive and cost-prohibitive. When conducting an application survey, focus on applications that meet the following criteria:

• Are of particularly high value to the organization.

• Would naturally benefit from integration into a single sign-on infrastructure.

• Are indicative of standard programming and deployment platforms within your organization.

• Are generally receptive to the identity management infrastructure.

• Are currently in the early process of deployment and might logically have time lines that coincide with the Access Manager deployment.

You might develop a spreadsheet that can be used to organize the information from the most promising applications. An overall metric can be developed to compare the value of the application to the complexity of its integration. This metric might be considered an application’s degree of fitness for deployment. An example of a highly fit application might be a web application that delegates authentication to an application server on which an Access Manager policy agent is installed for security. All user information would be stored in an LDAP directory.

An example of an unfit application might have a text-based interface, running on a mainframe computer. In this case, it would be advantageous to integrate other applications while waiting for a new version of the mainframe application.

The following sections describe types of information that can be gathered when evaluating your organization’s applications. This step also helps in determining the resources that will be protected.

Platform Information

General platform information, based on your existing technologies and hardware, can be used to assess the appropriateness of an application as a candidate for integration. Collected platform information might include the following:

• What operating system (including version) do the applications run on?

• Which web containers (including version) do the applications run in?

• What programming model was used to develop the applications ? (such as Java, ASP/.NET, or C)

• Are there plans to upgrade the applications? If so, what is the time line?

LOB applications might also be running third party applications (such as portals, content management databases, or human resource systems). These applications do not always deploy on platforms supported by Access Manager policy agents. If a policy agent is required, determine the deployment criteria of these applications and schedule their deployment based on the availability of a policy agent.

Security Models

It is important to document the existing security models used within the LOB applications. Typically, applications that use external authentication or authorization are candidates for deployment as well as applications that rely on external directory services. Security information might include the following:

• What authentication mechanisms are currently being used?

• Are their special authentication requirements (such as 2-factor authentication)?

• Is there a pluggable interface for external authentication mechanisms?

• What authorization mechanisms are currently being used?

• Can (or should) authorization be externalized?

• What user data repositories are being used? Can these be externalized?

• Who can access the application? Are there existing roles or groups in place? Under what special conditions are they granted access?

Lifecycle of a Session

An identity’s session lifecycle is an important topic to consider when evaluating authentication applications. Make sure you have a clear picture of how a user session is created, managed, and destroyed. Clearly document this process because it will be needed during the application’s integration.

Customization and Branding

Consider any specific branding or look and feel requirements for the application. Often times, it is important to maintain an individual look and feel or to simply maintain consistency of user experience. Ensure that any customization and branding requirements are noted with your application assessment because time must be scheduled for this activity.