WAS v8.5 > Secure applications > Secure web services > Secure web services > Web Services Security concepts

Web Services Security concepts for v5.x applications

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.

Subtopics

• Web Services Security specification—a chronology
  This chronology describes the process that has been used to develop the Web Services Security specifications. The chronology includes both the Organization for the OASIS and non-OASIS activities.
• Web Services Security support
  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 EE security specification.
• Web Services Security and Java Platform, Enterprise Edition security relationship
  This article describes the relationship between Web Services Security (message level security) model and the Java EE security model. It also includes information on Java EE role-based authorization checks.
• Web Services Security model in WAS
  The Web Services Security model used by WAS is the declarative model. WAS does not include any APIs for programmatically interacting with Web Services Security. However, a few Server Provider Interfaces (SPIs) are available for extending some security-related behaviors.
• Propagating security tokens
  In this example, security tokens are propagated using Web Services Security, the security infrastructure of the WAS, and Java EE security.
• Web Services Security constraints
  The Web Services Security model used by WAS 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.
• Overview of authentication methods
  The Web Services Security implementation for WAS supports the following authentication methods: BasicAuth, LTPA, digital signature, and identity assertion.
• Overview of token types
  Web Services Security defines the types of security tokens. The deployment descriptor extension file defines the types of tokens the message can accept.
• XML digital signature
  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).
• Default binding
  The default binding information is defined in the ws-security.xml file and can be administered by either the dmgr console or by scripting. Only default bindings for JAX-RPC applications are supported. Default bindings for JAX-WS applications are not supported.
• Default configuration for WAS
  For JAX-RPC applications, each application server, in WAS, uses a copy of the ws-security.xml file to define the default binding information for Web Services Security.
• Trust anchors
  A trust anchor specifies keystores containing 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.
• Collection certificate store
  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.
• Key locator
  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
  Keys are used for XML signature and encryption.
• Trusted ID evaluator
  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
  Login mappings, found in the ibm-webservices-bnd.xmi XML file, contains a mapping configuration. This mapping configuration defines how the Web Services Security handler maps the token < ValueType> element 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.
• XML encryption
  XML encryption is a specification developed by World Wide Web (WWW) Consortium (W3C) in 2002 containing 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).
• Request sender
  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 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.
• Request receiver
  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).
• Response sender
  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.
• Response receiver
  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 in a SOAP message
  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.
• Security token
  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 token support
  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 WAS identity used by the 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.

+

Search Tips   |   Advanced Search