Web Services have played a key role in integrating heterogeneous applications, particularly in cross domains. As part of identity management, Security Token Services are used for request and response tokens. However, we need multiple communication channels among Security Token Services when multiple applications in different domains try to reach other Web Services.

In this article we have proposed a Master Security Token Service (MSTS) that can act as a broker for all security authorization without duplicating the effort at every domain.

In a world of heterogeneous systems where each application is leveraging the services of other applications, a service-oriented analysis and design process has become significant. Web Services are sets of services used for integrating business processes and services, and can be accessed over the Internet or executed on a remote system hosting the Web Service requests using standard protocols. WS-Federation offers the opportunity of fulfilling the SSO behavior across domains. Security information can be shared across the domains of applications through federated identity, which is about identity information across security domains. Heterogeneous applications will have interactions through either Web Service requests or browser requests. While Web Service requests follow the WS-Security and WS-Trust standards, browser requests follow on how the service messages are secured and encoded with Http messages to transport among the resources.

While Web Services use is now predominant in many enterprises across domains using different protocols, the security of the Web Services is debatable, consequently federated identity management implementation for the integrated environment of various applications across domains using Web Services has become a hot topic for the reference architectural framework.

Federated identity management should do authentication, authorization, auditing, reporting, and upstream and downstream session management. Security Token Service (STS) implements the protocol for message formats and message exchange patterns as defined in the WS-Trust specification and WS-Secure Conversation will allow multiple Security Token Service requests. The main challenge is how to federate identity and establish connection in domains when multiple applications are in different domains. We can have independent security authentication using separate Security Token Services for each of the applications and each of the services, which involves sets of repeated activities. To minimize the effort of using multiple Security Token Services, we've identified and proven the architecture, which will have one Security Token Services Server called a Master Security Token Services Server. This will reduce the replication of management credentials and provide robust security since it's a centrally monitored server.

Proposed MSTS Framework
Figure 1 shows a reference architecture for managing the security of Web Services in a heterogeneous enterprise environment. It's common for organizations to have multiple domains and for each domain to have a separate Security Token Service Server. It creates a lot of complexity if these systems have to interact with each other securely. In the context of Service Oriented Architecture, we use WS-Security and WS-Trust specifications to secure these services. These services will also make use of a Security Token Service from each realm/domain. This will also create a lot of complexity since every STS in one realm/domain has to issue tokens to STS in other domains. In the architecture proposed below, MSTS will reduce the complexity by having fewer communication channels.

This architecture recommends creating a Master STS that doesn't belong to any realm/domain in particular. This central STS has to maintain bindings to the other STS from all the realms/domains. Suppose, for example, that a client from domain 3 wants to call a service from domain 2. It can call the Master STS and get a token to make a call on STS 2. Then the client can call STS 2 and get a token to call the service from domain 2. Only the Master STS has to maintain a trust relationship with all the other realms/domains rather than the individual realms/domains. This way managing the STS will be easy since only the Master STS has to be changed if any realms/domains are added or deleted. The same architecture can be extended to external realms/domains. You can treat any external realm/domain as another domain.

Conclusion and Future Work
Implementing an MSTS will reduce STS complexity and simplify the overall architecture of the enterprise applications. It will help manage STS connections. Going forward, we're focused on identity management with WS-Federation and SAML2.0. We're also planning to work on the persistence of token services.

References

• Shankar_Kambhampaty
• http://en.wikipedia.org/wiki/Webservice.
• Cesare Pautasso and Thomas Gschwind. Emerging Web Services Technology, Vol. II: Wewst 2007, Halle (Saale), Germany, November 2007. Selected Revised Papers; more by Cesare Pautasso and more by Thomas Gschwind.
• Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju. Web Services. Amazon.
• Klaus Aschenbrenner. Implement Secure .NET Web Services with WS-Security.
• Brokered Authentication: Security Token Service (STS)
• http://www4.java.no/javazone/2006/fossSOA-jan07(2).pdf.
• Web Services Seminar.
• Jason Baragry.
• Luciano Baresi, Elisabetta Di Nitto, Carlo Ghezzi, Sam Guinea. A framework for the deployment of adaptable web service compositions. 75-91.
• WS Federation.
• Federated Identity.
• How to: Create a Security Token Service.
• Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0 Microsoft Corporation.

• Developing Web Applications in a Clustered Environment Using WLST and Workshop
• Security Options for .NET Web Services
• Netegrity Publishes Reference Architecture to Simplify Web Services Security