Colm O hEigeartaigh

Subscribe to Colm O hEigeartaigh feed
Colm O hEigeartaigh
Updated: 10 hours 27 min ago

CXF 2.4.0 released

Wed, 04/20/2011 - 16:27
Apache CXF 2.4.0 has been released. CXF 2.4.0 contains a number of new and improved features in the security space. From the release statement:
WS-Security improvements including support for SAML2 tokens, improved
validation of security tokens, better performance, increased WS-I Basic
Security Profile compliance, and much more.If those new features seem familiar, it's because most of the new functionality is driven by WSS4J 1.6.0, which I've blogged extensively about over the last few months. Probably the most significant new security functionality in CXF 2.4.0 is greatly enhanced support for SAML Assertions. CXF 2.4.0 supports the ability to create, secure, process and validate SAML Assertions in accordance with the WS-Security 1.1 SAML Token Profile. I intend to blog in more detail how to use these new features in CXF 2.4.0 over the next while.

See Dan Kulp's blog for more in-depth thoughts on the new release.
Categories: Colm O hEigeartaigh

WSS4J 1.6.0 released

Fri, 04/15/2011 - 13:28
WSS4J 1.6.0 has been released:
The Apache Web Services team is pleased to announce the release of WSS4J 1.6.0. WSS4J 1.6.0 features support for SAML2 assertions, JSR-105 support, better spec compliance, performance work, support for trust-stores and a lot more besides. It is not API-compatible with the 1.5.x series of releases. For more information on the new features and changes in WSS4J 1.6.0 go to: To download WSS4J 1.6.0 go to: The Apache Web Services Team
Categories: Colm O hEigeartaigh

[WSS4J 1.6] Introducing Validators

Tue, 04/05/2011 - 14:18
WSS4J 1.6 introduces the concept of a Validator, for validating credentials that have been processed by a Processor instance. This task was covered by the JIRA WSS-266.

An inbound security header is processed by WSS4J by iterating through each child element of the header, and by calling the appropriate Processor implementation to deal with each element. In WSS4J 1.5.x, some processors perform validation on the received token (e.g. UsernameTokens), whereas others store the processing results for later verification by third-party WS-Handler implementations (e.g. Timestamp verification, Certificate trust verification). There are some problems with this approach:
  • It is not consistent, some processors perform validation, others do not.
  • There is a potential security hole, in that it is assumed third-party code will know to validate the credentials that the WSS4J processors do not validate.
  • WSS4J will continue to process the rest of the security header even if the Timestamp is invalid, or the certificate non-trusted, which could lead to denial-of-service attacks.
  • There is no separation of concerns between processing the token and validating the token. If you want to change how the token is validated, you must replace the processor instance.
WSS4J 1.6 has moved Timestamp verification and certificate trust validation back into the processing of the security header, thus solving the first three points above. The fourth point is met by the new concept of Validators, as well as some changes to the way Processors and CallbackHandler implementations are used in WSS4J 1.6.

In WSS4J 1.5.x, CallbackHandler implementations are used in different ways by different processors, sometimes they are expected to verify a password (as for processing UsernameTokens), and other times they are expected to supply a password (as for decryption). In WSS4J 1.6, CallbackHandler implementations are only expected to supply a password (if it exists) to the processors. The Processor implementations do not perform any validation of the security token, instead they package up the processed token, along with any (password) information extracted from the CallbackHandler, and hand it off to a Validator implementation for Validation.

The Processor implementations get the specific Validator implementation to use via the RequestData parameter, which in turn asks a WSSConfig object for the Validator implementation. If the Validator is null, then no Validation is performed on the received token. The Processor then stores the received token as normal. WSS4J 1.6 comes with several default Validators, which are:
  • NoOpValidator: Does no processing of the credential
  • TimestampValidator: Validates a Timestamp
  • UsernameTokenValidator: Validates a UsernameToken
  • SignatureTrustValidator: Verifies trust in a signature
  • SamlAssertionValidator: Checks some HOK requirements on a SAML Assertion, and verifies trust on the (enveloped) signature.
There are some additional WSSecurityEngineResult constants that pertain to the Validator implementations:
  • TAG_VALIDATED_TOKEN: Indicates that the token corresponding to this result has been validated by a Validator implementation. Some of the processors do not have a default Validator implementation.
  • TAG_TRANSFORMED_TOKEN: A Validator implementation may transform a credential (into a SAML Assertion) as a result of Validation. This tag holds a reference to an AssertionWrapper instance, that represents a transformed version of the validated credential.
To validate an inbound UsernameToken in some custom way, simply associate the NoOpValidator with the UsernameToken QName in the WSSConfig of the RequestData object used to supply context information to the processors. After WSS4J has finished processing the security header, then extract the WSSecurityEngineResult instance corresponding to the WSConstants.UT action, and perform some custom validation on the token.

An example of how to add a custom Validator implementation is the STSTokenValidator in CXF 2.4.0. The STSTokenValidator tries to validate a received SAML Assertion locally, and if that fails, it dispatches it to a Security Token Service (STS) via the WS-Trust interface for validation. It also supports validating a UsernameToken and BinarySecurityToken in the same manner. The SecurityConstants class defines some configuration tags for specifying a custom validator for inbound SAML1, SAML2, UsernameToken, BinarySecurityToken, Signature and Timestamps. The STSTokenValidator can be configured by associating it with the appropriate configuration tag.
Categories: Colm O hEigeartaigh

[WSS4J 1.6] SAML property changes

Sun, 03/13/2011 - 16:02
A previous blog entry described how WSS4J 1.6 will have support for creating, parsing, signing, verifying, etc. SAML 2 assertions. WSS4J 1.5.x had limited support for creating and signing SAML 1.1 assertions via the default SAMLIssuer implementation, combined with a properties file. These configuration values consisted of:
  • - The SAML Issuer implementation (defaults to "").
  • - The crypto properties file corresponding to the issuer crypto instance, if the assertion is to be signed.
  • - The KeyStore alias for the issuer key.
  • - The KeyStore password for the issuer key.
  • - The issuer name
  • - Whether to send the key value or the X509Certificate. Defaults to: "false".
  • - The Subject DN.
  • - The Subject qualifier.
  • - The authentication method (e.g. "password").
  • - The confirmation method, either "senderVouches" or "keyHolder".
The configuration tags for WSS4J 1.5.x completely controlled the creation and signing of a SAML 1.1 Assertion, and hence produced only a very limited set of possible assertions.  WSS4J 1.6 takes a different approach, where the configuration tags correspond to the configuration of the issuer, i.e. whether to sign the assertion or not, the issuer name, crypto instance, etc. All instructions about how to create the SAML Assertion itself, are left to a CallbackHandler implementation.

The following configuration tags in WSS4J 1.6 are exactly the same as in WSS4J 1.5.x:
  • - The SAML Issuer implementation (defaults to "").
  • - The crypto properties file corresponding to the issuer crypto instance, if the assertion is to be signed.
  • - The KeyStore alias for the issuer key.
  • - The KeyStore password for the issuer key.
  • - The issuer name
  • - Whether to send the key value or the X509Certificate. Defaults to: "false".
The following configuration tags are new to WSS4J 1.6:
  • - Whether the SAMLIssuer implementation will sign the assertion or not. Defaults to: "false".
  • - The name of the SAML CallbackHandler implementation used to populate the SAML Assertion.

[WSS4J 1.6] Basic Security Profile 1.1 compliance

Tue, 03/08/2011 - 14:44
The Basic Security Profile (BSP) 1.1 specification provides an industry-standard way of making sure that different WS-Security stacks can communicate with each other, by clarifying and narrowing the scope of the various WS-Security standards. WSS4J 1.5.x does not implement the BSP in any meaningful way. The WSSConfig class supports a "isWsiBSPCompliant" method (default is false), which will enable the generation of an InclusivePrefix list for signature generation, something that is mandated by the BSP spec.

WSS4J 1.6 provides support for the BSP 1.1 specification, in so far as it pertains to the core WS-Security specifications that WSS4J supports. The enforcing of BSP compliance for inbound messages is controlled by the WSSConfig class, as per WSS4J 1.5.x. An important change is that BSP compliance is now turned on by default. In addition, a new WSHandlerConstants configuration parameter has been added so that BSP compliance can be controlled via a WSHandler implementation.