 — Sidharth Mishra technical product manager, identity management, Sun Microsystems
Sidharth Mishra, technical product manager for identity management at Sun, joined the company in 2001 as an engineer for Sun Java System Directory Server. Later on, he transferred to Market Development Engineering and focused on managing partner relationships in the identity arena before switching to product management two years ago. The ubiquity of the Web has seen the emergence of Web services as a dynamic means of obtaining real-time data, which, if confidential in nature, requires protection. Recently, I interviewed Sidharth for an explanation of the nuances involved in securing Web services and the role played by OpenSSO, Sun's open-source project for access management and federation. OpenSSO is an identical twin of Sun Java System Access Manager, a core product for managing single sign-on, federation, and secure Web services. What Are Web Services?
"Web services are dynamic programs that enable data and applications to interact with each other on the Web through ad hoc connections—without any human intervention whatsoever," Sidharth says. The main advantage of Web services is their flexibility and versatility: They support many architectures and are independent of platforms and designs. How does a Web service differ from a Web application? "A Web service is normally intended to be a distributed application component. Its clients are other applications, not human beings. A Web application involves interactions with users, who would perform certain tasks, like clicking a button, to cause the application to proceed to the next step," Sidharth explains. An example of a Web service is a stock-quote service, to which any application can connect and retrieve real-time quotes. Another example is a Web service from a credit bureau from which loan services request the credit history of prospective borrowers. In that case, the data interaction must be protected to preserve its confidentiality. How Are Web Services Secured?
"Web services transmit data in the clear so the security risks are formidable," Sidharth points out. "Features like flexible data accessibility that make Web services attractive are at odds with traditional security models and approaches. Traditionally, protection is at the transport layer through SSL [Secure Sockets Layer] or TLS [Transport Layer Security], but those mechanisms are not adequate for securing Web services. SSL and TLS work well for applications, which have two endpoints. Web services are not always point-to-point, however, and can inherently and simultaneously interact with multiple Web services." Ironically, a key advantage for Web services—flexibility—thus becomes a challenge with respect to security. Enter application-level or message-level security, which introduces security at the Simple Object Access Protocol (SOAP) message level, insulating messages from security attacks before their arrival at the destination. "Of course, for that to happen," observes Sidharth, "we must take advantage of standard protocols and mechanisms for attaching security-related information targeted at specific recipients." What Are the Standards for Message-Level Security and How Does OpenSSO Help?
Standards bodies that help you secure Web services abound. Sidharth cites three prominent ones:
OpenSSO ensures complete message-level security by supporting the popular security standards for Web services and for client applications that are based on the following:
In addition, application containers, such as the open-source GlassFish Project, support Java Specification Request (JSR) 196 (Java Authentication Service Provider Interface for Containers) for implementing message-level security. "All those tools work together and render deployment of Web services seamless, transparent, and, above all, secure," adds Sidharth. How Does OpenSSO Act As a Security Token Service?
A Security Token Service (STS), a foundational component of an organization's security infrastructure for Web services, answers the question "How does a Web service verify the credentials presented by a WSC?" Here's how:
A key benefit of STS is that it can translate tokens that are based on the security policy of the WSC and WSP. For example, a request that is issued in X.509 is translated to Security Assertion Markup Language (SAML) 2.0. Sidharth clarifies: When configured as an STS, OpenSSO acts as a generic WSP that enables the exchange of interoperable security tokens between WSPs and WSCs. OpenSSO performs three primary tasks:
Figure 1 illustrates the relationships and process flow.  Figure 1: OpenSSO Acting As a Security Token Service
Why Adopt OpenSSO?
"OpenSSO ably handles security requirements in real-time deployments for Web services," emphasizes Sidharth. "Naturally, implementation of standards requires complex operations. In the case of OpenSSO, however, those operations all occur behind the scenes. That means that for configurations, all you need to do is specify a few parameters—the token exchange mechanisms for the WSP, WSC, and so forth. You're then assured that message exchanges among the parties concerned are protected." A commercial release of OpenSSO, complete with a support model, is forthcoming soon. Watch SDN's identity management hub for an announcement. Meanwhile, do check out the project and its many capabilities. References
|
| ||||||||||||||
 | |
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
Print-friendly Version
