Introduction


It is a common approach that any enterprise would grant the access to information per application basis. The employee would need a username and a password to access the human resource system, and another password (and probably another username) to access the technical reports. This issue grows higher as the size of the enterprise gets bigger, especially for administrative assistants and managers who have to memorize different passwords besides performing their usual tasks.

Now, what if the enterprise is distributed across a wider network; the Internet for example? The communication will be less protected and an extra caution should be given to achieve a secure confidential transmission of data. This issue becomes more noticeable with web services due to some factors:

·         It is the most obvious example of communicating different resources across different platforms and/or networks.

·         The communicating partners are likely to establish the communication with no human interaction.

Business Needs


The student information services suite at Carnegie Mellon is intended to migrate into a new architecture with a layered approach. The new architecture continues to support different parties that consume the services provided. New applications will be developed; old applications may need to be edited to be compatible with the new environment. More consideration should be provided for web services that would form the interaction with the exterior systems. They all should pass through a sort of centralized authentication and authorization procedure. The new system needs to be supported by providing a centralized security management features.


Securing Web Services


All the common technologies that secure web applications mostly use SSL which have been doing fine for the past years. The main issue with this approach is the overhead resulted from securing the whole transport channel rather than securing the message itself. So, how do you secure messages rather than transport? What Web Services Security defines is a mechanism for adding three levels of security to SOAP messages.

·         Authentication Tokens: they enable clients to send credentials certificates for the purpose of authentication within the SOAP message headers.

·         XML Encryption: encrypt the SOAP message body or part of it to insure message confidentiality. Various encryption methods are supported.

·         XML Digital Signature: enable SOAP messages to be digitally signed to insure message integrity. If the message was altered in the route, the signature becomes invalid.

The issue with WS-Security is that it requires propagation of credentials or security tokens from consumers to providers which introduce many issues like the need of duplicated identities for each user in all possibly used applications.

Proposals


IBM proposed several applications that are believed to manage the security of the IT infrastructure; IBM Tivoli products are among these suggestions beside BEA AquaLogic and Sun Java System Access Manager.

IBM Tivoli

Identity Manager (TIM)


            This product provides identity management that enables the administrator to determine who can enter the protected system, what can be accessed and what is needed to do the task.


Access Manager (TAM)


It is an authentication solution for corporate web services, operating systems, and existing applications. Tivoli Access Manager provides the required authorization to protect the enterprise resources from unauthorized insiders and outsiders.


Implementation of Tivoli’s Products


The solution provided by IBM Tivoli Access Manager is to provide a set of trusted servers hosting trusted applications on physically separated servers. It is implemented by installing a WebSeal in front of the internal HTTP Server, which provides routing services to the trusted servers (Figure 1). This would allow applications to consume services from one another without further authentication. Servers and applications that are not trusted are prevented from consuming services hosted in trusted servers. [1]

Figure 1: Physical Architecture of the trusted server solution

The issue with this solution is that any user who has the ability to login to a trusted server would be able to access all other servers. This leakage exposes the enterprise to a clear authorization issue which needs another solution to handle. IBM Tivoli Identity Manager would be needed to act in the role of authorizer who authorizes, monitors, and logs all invokes of services. It is clear that this adds extra layer of implementation that increases the complexity of the solution.

Sun Java System Access Manager (SAM)


It is a set of software components that support enterprise applications distributed across a network. It integrates authentication and authorization services to protect the network communication and resources. Its single sign on feature is a powerful service that can be embedded and controlled in almost any enterprise system. Moreover, it secures the communication between systems that use web services to communicate.

The system provides centralized agent configuration management. All systems and applications that need to be secured are integrated with local agents that authenticate them to the network. Different agents are needed to support different platforms or applications. All security updates are synchronized between the agents and the central system.

Access Control Features


Besides configuring agents at one place, SAM contains an embedded directory server that can be used as a user store or configuration store. It also can consume third party tokens from other web access management systems, like CA Siteminder. 

Web Services Security Features


The security token service centralizes security for web services and handles orchestration of standards-based tokens between web services clients and providers. With the multi-protocol web services security hub, clients and providers can speak different protocols and conduct single sign on and single logoff for a session across multiple federation protocols.

3rd party WAM Token Support - SAM can have a single circle of trust between SAM Enterprise and 3rd party web access management solutions including Oracle Access Manager and CA Siteminder.

How it works?


After installing and configuring the SAM central system, an agent should be installed in each server that is part of the secured enterprise.  Different agents are needed for different landscapes and services, but they all act in harmony that aggregate the security rules among the enterprise.

Recommendation


There are several advantages of this approach over the IBM Tivoli one. First, there is no need to separate the trusted applications and servers physically from un-trusted ones. The suitable agent is installed in the designated server, and the applications hosted in that servers need to be adjusted to work with the agent (figure 2).

Figure 2: Agent-based Architecture

Another advantage is the access and authorization management where SAM provides comprehensive management of both roles among all applications. Each agent would send the request in behalf of the user and the manager will automatically authenticate the request toward required applications and services.

Finally, since it is developed in Java, it is designed to run everywhere; in most systems, and to support closed and opened applications. SAM provides secure communication channel between variety of applications running on different systems and platforms; like .NET applications. It also supports open source and legacy applications.

References

[1]: Securing Web Services with TAM, http://www.ibm.com/developerworks/tivoli/library/t-swstam/index.html 11/27/2008

[2]: CMU High Level SOA Reference Architecture, By IBM S3 Team 05/09/2008