Chapter 13 Delivering Identity Web Services

OpenSSO Enterprise provides client interfaces for authentication, authorization, session, identity management and auditing in Java, in C (C++) and in HTTP(S)/XML. These interfaces are used by web and Java EE policy agents as well as custom applications developed externally. Now, OpenSSO Enterprise also delivers web services that expose these identity functions as simple web services. This chapter contains information on the following topics:

• About Identity Web Services

• Identity Web Service Styles

• Identity Web Services Architecture

About Identity Web Services

A web service is a black-box component that can be accessed using exposed endpoints. OpenSSO Enterprise uses this concept to expose the following security and identity related functions as Identity Web Services:

• authenticate (user credential verification)

• authorize (an authenticated identity's access permission)

• attributes (an authenticated identity's profile)

• log (record and audit actions)

Identity Web Services allow developers to easily invoke these functions without any knowledge of OpenSSO Enterprise, resolving the problems of enabling web service discovery and invocation, security, privacy and ease-of-deployment. Keeping Identity Web Services simple allows an application developer to consume them by pointing an integrated development environment (IDE) to the service's URL and allowing it to generate the stub code that wraps a call to the service. Identity Web Services are supported on:

• NetBeans

• Eclipse

• Visual Studio

Identity Web Services does not require the Client SDK or deployment of an agent or proxy to protect a resource.

Within Identity Web Services the user enters authentication credentials using a JavaServer Pages (JSP). The user data is then forwarded to the composite application which authenticates the web service request. The application may then authorize the operation and obtain the user's profile. See Identity Web Service Styles for more information.

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.

Identity Web Services Architecture

In an Identity Web Service interaction, the user interacts with an application which then calls either of the Identity Web Services to authenticate and authorize the identity, create personalized services, and log the actions. When contacted at the respective URL, OpenSSO Enterprise obtains the user profile from the appropriate identity repository for authentication and the policy configuration from the appropriate configuration data store, and writes the actions to the configured log file. Figure 13–1 illustrates the components of the Identity Web Services.

Figure 13–1 Components within the Identity Services Interactions