Identity Web Service Styles

OpenSSO Enterprise Identity Web Services have been developed in two styles. The decision on which style to use is the initial choice when designing your application. The styles are:

• The SOAP and Web Services Description Language (WSDL) style is the traditional approach preferred by the service-oriented architecture (SOA) business intelligence community. See SOAP and WSDL.

• The REpresentational State Transfer (REST) style is a newer approach preferred by the Web 2.0 community. (A REST service is referred to as RESTful.) See REST.

developers.sun.com has an excellent three part article called Securing Applications with Identity Services which contains IDE configuration information and procedures.

SOAP and WSDL

SOAP, WSDL, and XML Schema have become the standard for exchanging XML-based messages among applications. To implement this style, the IDE must obtain the WSDL, generate the client stubs, and set up the JavaServer Pages (JSP) for the Identity Web Services. Once completed, the SOAP Identity Web Services are accessible with the following URLs:

• http://host_machine.domain:8080/opensso/identityservices/IdentityServices

• http://host_machine.domain:8080/opensso/identityservices?WSDL

This style may be appropriate when:

• A formal contract must be established to describe the interface that the web service offers. A WSDL is needed to describe the web service interfaces including details such as messages, operations, bindings, and location.

• The architecture must address complex requirements including security, financial transactions, provider trust and the like.

• The architecture needs to handle asynchronous processing and invocation. The infrastructure provided by standards such as WSRM and APIs such as JAX-WS can be leveraged out of the box.

REST

The internet is comprised of resources. Clients may access resources with a URL. When requested, a representation of the resource (an HTML page) is returned. The result of the user clicking a link on the page is that another resource is accessed (possibly an image, video, or another HTML page). Each new representation places the client into a state that is different from the previous state. Thus, the client application changes state with each accessed resource representation. REST is a design architecture in which a web service is viewed as a resource identified by a URL. The web service client then accesses it using a globally defined set of remote methods that describe the action to be performed. REST is not a standard; you can only understand it, and design web services in the REST style. REST does, though, use standards including:

• HTTP

• URLs

• Resource representations (XML, HTML, GIF, JPEG, and others)

• MIME types (text/xml, text/html, image/gif, image/jpeg, and others)

RESTful services are accessed using a generic interface; in OpenSSO Enterprise it is the GET, POST, PUT, and DELETE HTTP methods. The RESTful Identity Web Service is accessible at http://host_machine.domain:8080/opensso/identity. Because these web services are exposed using the HTTP methods, they can be accessed from a browser. This style may be appropriate when:

• The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server.

• Bandwidth needs to be limited. REST is particularly useful for limited-profile devices such as PDAs and mobile phones, where the XML payload must be restricted.

• Aggregation into existing web sites is needed. Web services can be exposed with XML and consumed by HTML without significantly reinventing the existing web site architecture.

OpenSSO Enterprise REST interfaces currently support only username and password authentication.