InnerhalbNach weiteren Dokumenten suchenSupport-Ressourcen |  Dieses Buch im PDF-Format herunterladen (746 KB)
Chapter 1 Authentication Agents for Web ServicesSun Java™ System web services security providers are authentication agents integrated into a Java™ Platform, Enterprise Edition (Java EE) compatible web container. This chapter provides introductory material and background on these authentication agents. It includes the following sections: Web ServicesA web service is an application that exposes some type of functionality using a platform-independent interface. Enterprises use web services as a mechanism for allowing their applications to cross network boundaries and communicate with those of their partners, customers and suppliers. Web services are accessed by sending a request to one of the service's defined endpoints. The following open technologies are used to allow this access.
The built-in openness of these technologies unfortunately though creates security risks. The following security requirements have been identified and must be supported to insure that the communications between a web service provider (WSP) and a web service client (WSC) are not compromised.
Securing web services communications was initially addressed on the transport level, relying on securing the HTTP transmissions themselves using Secure Sockets Layer (SSL). This is not adequate though when access to an application is requested through an intermediary. The solution to this is to encrypt the entire request using message level security before it is sent. In message level security, security information is contained within the SOAP message or attachment, making it independent of the transport level security. The request may then securely pass through multiple intermediaries before reaching its intended receiver for decryption. The following illustration depicts message level security. 
Java Authentication Service Provider Interface for ContainersThere are a number of organizations that work on web services security specifications, guidelines, and tools including the World Wide Web Consortium (W3C), the Organization for Advancement of Structured Information Standards (OASIS), the Liberty Alliance Project and the Java Community Process (JCP). The JCP primarily guides the development and approval of Java technical specifications, one of which is the Java Specification Request (JSR) 196. JSR 196 is a draft of the Java Authentication Service Provider Interface for Containers. It defines a standard service provider interface (SPI) with which a message level authentication agent can be developed for Java EE containers on either the client side or the server side. These agents may establish the authenticated identities used by the containers allowing:
Note – The JSR 196 draft specifications are available at http://www.jcp.org/en/jsr/detail?id=196. A typical interaction between a WSC and a WSP begins with a request from the WSC. The container to which the WSP is deployed receives the request and dispatches it to the correct web service to perform the requested operation. When the web service completes the operation, it creates a response that is returned back to the client. The following illustration illustrates this process in more detail with the steps provided below it. This process illustrates a scenario when both client and service web containers employ the Java Authentication SPI. 
The JSR–196 SPI is structured so that the security processes can be delegated to an authentication agent at any of four interaction points in this scenario. The four points represent the methods of the corresponding ClientAuthModule and ServerAuthModule interfaces defined by the SPI and include:
Thus, when a WSC and WSP are both deployed in a Java EE web container protected by a JSR–196 authentication agent, the initial request from the WSC is intercepted by the authentication agent on the client side. The client side agent queries a trusted authority (for example, the Discovery Service in Access Manager) to retrieve the necessary authorization credentials and secure them to the request. The request is then passed to the WSP. The authentication agent on the provider side receives the request to validate the authorization credentials. If validation is successful, the request is exposed to the web service and a response is created using the sender's credentials and the application specific request. The response is then intercepted by the authentication agent on the provider side to secure it and return it to the WSC. Upon receiving the response, the authentication agent on the client side validates it and dispatches it to the client application. This is illustrated in the following graphic. 
Sun Java System Access Manager Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web ServicesIn general, securing web services involves establishing trust between a WSC and a WSP. For identity-based web services specifically (for example, a calendar service), the WSP would have to trust the WSC to have authenticated the user, or the WSC would have to include the user's credentials as part of the web service request. The distinguishing factor is that identity-based web services authenticate both the WSC and the user's identity. (The user must be authenticated so that the WSC can send the user's token to the WSP in a SOAP security header.) The Sun Java System Access Manager Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services plugs into Application Server Platform Edition 9.0, provides message level security, and supports both Liberty Alliance Project token profiles as well as Web Services-Interoperability Basic Security Profiles (WS-I BSP). (A profile defines the HTTP exchanges required to transfer XML requests and responses between web service clients and providers.) Note – More information on Application Server Platform Edition 9.0 can be found in the collection of documentation provided for the product located at http://docs.sun.com/coll/1343.3. This release of the agent uses an instance of Access Manager for all authentication decisions. Web services requests and responses are passed to Access Manager authentication modules using standard Java representations based on the transmission protocol. Currently, the Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services provides the following agents: HTTP Authentication AgentThe HTTP authentication agent protects the endpoints of a web service that uses HTTP for communication. After the HTTP authentication agent is deployed in an instance of Application Server on the WSP side, all HTTP requests for access to web services protected by the agent are redirected to the login and authentication URLs defined in the Access Manager AMConfig.properties file on the WSC side. AMConfig.properties is located in javaee.home/domains/domain_name/config when the Java Platform, Enterprise Edition (Java EE) 5 SDK is installed and in javaee.home/addons/amserver when the Java EE 5 Tools Bundle is installed. The configurable properties are:
Note – Application Server 9 has the ability to configure only one HTTP agent per instance. Therefore, all authentication requests for all web applications hosted in the container will be forwarded to the one configured agent. When the WSC makes a request to access a web application protected by an HTTP authentication agent (1 in the illustration below), the agent intercepts the request and redirects it (via the browser) to Access Manager for authentication (2). Upon successful authentication, a response is returned to the application, carrying a token as part of the Java EE Subject (3). This token is used to bootstrap the appropriate Liberty ID-WSF security profile. If the response is successfully authenticated, the request is granted (3). Note – For this release, the HTTP authentication agent is used primarily for bootstrapping. Future releases will contain information on how to protect web applications. The following figure illustrates the interactions described.  Note – The functionality of the HTTP Provider agent is similar in to that of the Sun Java System Access Manager Java EE agents when used in SSO ONLY mode. This is a non restrictive mode that uses only the Access Manager Authentication Service to authenticate users attempting access. For more information on Java EE agents, see the Sun Java System Access Manager Policy Agent 2.2 User’s Guide. SOAP Authentication AgentThe SOAP authentication agent secures SOAP messages between a WSC and a WSP. The agent can be configured for use as an authentication provider on either the WSC server or the WSP server. This initial release encapsulates the Liberty Identity Web Services Framework (Liberty ID-WSF) SOAP Binding Specification as implemented by Access Manager and supports the following: Note – The configuration process for the SOAP authentication agent is described in Installing the Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services. Supported Liberty Alliance Project Security TokensIn a scenario where security is enabled using Liberty Alliance Project tokens, the HTTP client requests (via the WSC) access to a service. The HTTP authentication agent redirects the request to the Access Manager Authentication Service for authentication and to determine the security mechanism registered by the WSP and obtain the security tokens expected. After a successful authentication, the WSC provides a SOAP body while the SOAP authentication agent on the WSC side inserts the security header and a token. The message is then signed before the request is sent to the WSP. When received by the SOAP authentication agent on the WSP side, the signature and security token in the SOAP request are verified before forwarding the request on to the WSP itself. The WSP then processes it and returns a response, signed by the SOAP authentication agent on the WSP side, back to the WSC. The SOAP authentication agent on the WSC side then verifies the signature before forwarding the response on to the WSC. The following diagram illustrates the interactions as described.  The following Liberty Alliance Project security tokens are supported in this release:
Supported Web Services-Interoperability Basic Security Profile Security TokensIn a scenario where security is enabled using Web Services-Interoperability Basic Security Profile (WS-I BSP) tokens, the HTTP client requests (via the WSC) access to a service. The SOAP authentication agent redirects the request to the Access Manager Authentication Service for authentication and to determine the security mechanism registered by the WSP and obtain the expected security tokens. After a successful authentication, the WSC provides a SOAP body while the SOAP authentication agent on the WSC side inserts the security header and a token. The message is then signed before the request is sent to the WSP. When received by the SOAP authentication agent on the WSP side, the signature and security token in the SOAP request are verified before forwarding the request on to the WSP itself. The WSP then processes it and returns a response, signed by the SOAP authentication agent on the WSP side, back to the WSC. The SOAP authentication agent on the WSC side then verifies the signature before forwarding the response on to the WSC. The following diagram illustrates the interactions as described.  The following WS-I BSP security tokens are supported in this release.
|
|