IBM® supports Web Services Security, which is an extension of the IBM web services engine, to provide a quality of service. The WebSphere® Application Server security infrastructure fully integrates Web Services Security with the Java™ Platform, Enterprise Edition (Java EE) security specification.
This chronology describes the process that has been used to develop the Web Services Security specifications. The chronology includes both the Organization for the Advancement of Structured Information Standards (OASIS) and non-OASIS activities.
IBM® supports Web Services Security, which is an extension of the IBM Web services engine, to provide a quality of service. The WebSphere® Application Server security infrastructure fully integrates Web Services Security with the Java Platform, Enterprise Edition (Java EE) security specification.
This article describes the relationship between Web Services Security (message level security) model and the Java Platform, Enterprise Edition (Java EE) security model. It also includes information on Java EE role-based authorization checks.
The Web Services Security model used by WebSphere Application Server is the declarative model. WebSphere Application Server does not include any application programming interfaces (APIs) for programmatically interacting with Web Services Security. However, a few Server Provider Interfaces (SPIs) are available for extending some security-related behaviors.
In this example, security tokens are propagated using Web Services Security, the security infrastructure of the WebSphere Application Server, and Java Platform, Enterprise Edition (Java EE) security.
The Web Services Security model that is used by WebSphere Application Server is the declarative model. A version 5.x application must be secured with Web Services Security by defining the security constraints in the IBM extension deployment descriptors and in IBM extension bindings.
The Web Services Security implementation for WebSphere Application Server supports the following authentication methods: BasicAuth, Lightweight Third Party Authentication (LTPA), digital signature, and identity assertion.
Web Services Security defines the types of security tokens. The deployment descriptor extension file defines the types of tokens that the message can accept.
XML-Signature Syntax and Processing (XML signature) is a specification that defines XML syntax and processing rules to sign and verify digital signatures for digital content. The specification was developed jointly by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF).
The default binding information is defined in the ws-security.xml file and can be administered by either the administrative console or by scripting. Only default bindings for JAX-RPC applications are supported. Default bindings for JAX-WS applications are not supported.
For JAX-RPC applications, each application server, in WebSphere Application Server, uses a copy of the ws-security.xml file to define the default binding information for Web Services Security.
A trust anchor specifies keystores that contain trusted root certificates that validate the signer certificate. The request receiver and the response receiver use these keystores to validate the signer certificate of the digital signature.
A collection certificate store is a collection of non-root, certificate authority (CA) certificates and certificate revocation lists (CRLs). This collection of CA certificates and CRLs is used to check the signature of a digitally signed SOAP message.
A key locator (com.ibm.wsspi.wssecurity.config.KeyLocator) is an abstraction of the mechanism that retrieves the key for digital signature and encryption.
Keys are used for XML signature and encryption.
The trusted ID evaluator is an abstraction of the mechanism that evaluates whether the given ID name is to be trusted. The trusted ID evaluator is typically used by the eventual receiver in a multi-hop environment.
Login mappings, found in the ibm-webservices-bnd.xmi Extended Markup Language (XML) file, contains a mapping configuration. This mapping configuration defines how the Web Services Security handler maps the token <ValueType> element that is contained within the security token extracted from the message header, to the corresponding authentication method. The token <ValueType> element is contained within the security token extracted from a SOAP message header.
Extensible Markup Language (XML) encryption is a specification developed by World Wide Web (WWW) Consortium (W3C) in 2002 that contains the steps to encrypt data, the steps to decrypt encrypted data, the syntax to represent XML encrypted data, the information used to decrypt the data, and a list of encryption algorithms such as triple Data Encryption Standard (DES), Advanced Encryption Standard (AES), and Rivest-Shamir-Adleman algorithm (RSA).
The security handler on the request sender side of the SOAP message enforces the security constraints, located in the ibm-webservicesclient-ext.xmi file, and bindings, located in the ibm-webservicesclient-bnd.xmi file. These constraints and bindings apply both to Java Platform, Enterprise Edition (Java EE) application clients or when web services are acting as a client. The security handler acts on the security constraints before sending the SOAP message. For example, the security handler might digitally sign the message, encrypt the message, create a time stamp, or insert a security token.
The request receiver defines the security requirement of the SOAP message. The security handler on the request receiver side of the SOAP message enforces the security specifications that are defined in the IBM extension deployment descriptor (ibm-webservices-ext.xmi) and bindings (ibm-webservices-bnd.xmi).
The response sender defines the security requirements of the SOAP response message. The security handler acts on the security constraints that are defined for the response in the IBM extension deployment descriptors.
The response receiver defines the security requirements of the response received from a request to a web service. The security constraints for response sender must match the security requirements of the response receiver. If the constraints do not match, the response is not accepted by the caller or the sender.
Identity assertion is a method for expressing the identity of the sender (for example, user name) in a SOAP message. When identity assertion is used as an authentication method, the authentication decision is performed based only on the name of the identity and not on other information, such as passwords and certificates.
A security token represents a set of claims made by a client that might include a name, password, identity, key, certificate, group, privilege, and so on.
Pluggable security token support provides plug-in points to support customer security token types, including token generation, token validation, and client identity mapping to a WebSphere Application Server identity that is used by the Java Platform, Enterprise Edition (Java EE) authorization engine. Moreover, the pluggable token generation and validation framework supports XML-based tokens to be inserted into the web service message header and validated on the receiver-side validation.