What's New in Metro 2.1 Security
By kumarjayanti on Feb 27, 2011
As most of you are aware Metro 2.1 integrates into GlassFish Open Source Edition V3.1 release. Project Metro is composed of the JAXWS runtime as the core along with JAXB plus implementation of the all the WS-\* specifications (a.k.a WSIT).
The WSIT workspace has been modularized as part of the GlassFish V3.1/Metro 2.1 release and now uses maven as its build system. This is in line with the larger GlassFish V3.X modular design. As part of this the Metro Security source code which was formerly located under the project (XWSS) is now an integral part of the WSIT workspace and currently builds as two modules (wsit/ws-sx/wssx-api, wsit/ws-sx/wssx-impl).
- Support for Policy-Alternatives (Preliminary)
- Support for JAAS KeyStoreLoginModule
- High Availability of Nonce Cache
- High Availability of SecureConversation Sessions
- Support for Signing Tokens not in message via STR-Transform
- WS-I BSP 1.1 and RSP 1.0 Compliance
- Support for RSA-SHA256 and higher bit SignatureAlgorithms
- WebServices Interoperability with other Oracle Products
Support for Policy Alternatives
WS-Policy defines a policy to be a collection of policy alternatives, where each policy alternative is a collection of policy assertions. Till date most of the usages of Policy in Metro WebServices would have a Single Policy Alternative under the wsp:policy element, something like this :
<wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > <wsp:ExactlyOne> <wsp:All> <sp:Basic256Rsa15 /> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
But in the context of security and possibly in other WS-\* areas there can be a need for the WebService to accept different types of end-user authentication tokens. For example a particular client of the WebSerivce might only be able to authenticate using Username/Password mechanims, whereas another client might want to use Certificates.
Policy-Alternatives as defined by WS-Policy provide the underlying framework in which a WebService can advertise it ability to accept multiple forms of client-authentication tokens.
The implementation of Policy-Alternatives in Metro Security is based on a Generic Framework that defines an SPI and treats Alternatives as First-Class Citizens. However for this release of Metro 2.1 the implementation of the SPI supports Alternatives that take the following restricted form :
So here the WebService Policy has two alternatives, one having SymmetricBinding + UsernameToken (as-SignedSupportingToken) and the other alternative having AsymmetricBinding + SAMLToken (as-SignedSupportingToken). From an authentication token perspective the WebService is indicating that it can accept either a Signed UsernameToken or a Singed SAMLToken.
The default SPI implementation tries to distinguish alternatvies by looking at the SingedSupportingToken. And it currently tries to recognize only a SAML or UsernameToken under the SingedSupportingTokens. If the implementation is unable to select an alternative upon receiving the client message then an exception would be thrown. If the Once the Alternative is selected the incoming message's inferred policy has to then completely match the policy of the selected alternative.
Also note that the alternatives support is primarily on the server side for a server to advertise the kinds of alternatives it can accept. For the client side the client would still have to choose a particular Alternative and create a custom localized wsit-client.xml which references the single-alternative that the client wishes to use. This choice would be based on the kind of Authentication Token the client wishes to use for Authentication.
Note that the Metro runtime on the client side would arbitrarily pick one of the alternatives when provided with a WSDL containing multiple alternatives.
In future releases the support for the kind of alternatives will be improved based on developer feedback and customer needs. A fully generic implementation of PolicyAlternatives in the context of the WS-Policy and WS-SecurityPolicy universe would require dealing with the general problem of Policy-Equivalence in the presence of wild-cards and exceptions.
Support for JAAS KeyStoreLoginModule
This feature tries to utilize the publicly available JDK login module com.sun.security.auth.module.KeyStoreLoginModule.
Configuration of KeyStoreLoginModule is supported for both pure JAXWS based WebServices as well as JSR-109 WebServices deployed on GlassFish. Of particular interest is the ability to use PKCS11 stores with this LoginModule. This is documented in the JavaSE PKCS11 guide. The post here further explains the use of this feature in Metro Security.
High Availability of NonceCache
The Metro 2.1 release supports LoadBalancing and HighAvailability of WebServices for the first time and it aligns itself with the larger release goal of GlassFish V3.1. There will be posts from other Metro developers who would talk in more detail about the general LoadBalancing and HighAvailability support in metro ( I shall point them out to soon in another post).
If you are not aware the WSS UsernameToken can contain a Nonce when the Password Digest Authentication is enabled :
or when Nonce is explicitly enabled under the UsernameToken as below :
The Metro SecurityRuntime caches Nonce values it receives in a Global NonceCache. Nonces remain in the NonceCache for a period specified by the property (under GlassFish 3.1 security-service) "MAX_NONCE_AGE". Whenever the runtime detects a repeated Nonce it would throw a SOAPFault back to the client indicating Nonce Replay. This provides protection against replay attacks. The default value of the MAX_NONCE_AGE property when not specified explicitly is 900000 milliseconds.
In Metro 2.1/GlassFish 3.1 when running in HighAvailability mode the NonceCache becomes highly available by using the GlassFish 3.1 BackingStore API's. Note an application (WebService in this case) can be made highly available by specifying the --availabilityenabled option to the glassfish deploy command (asadmin deploy --availabilityenabled=true <other options> application-archive)
Refer to the GlassFish 3.1 High Availability Administration Guide from the GlassFish OSE V3.1 Documentation for more details on High Availability support.
High Availability of SecureConversation Sessions
When a secure webservice is deployed in high availability mode (as described above) then any SecureConversation Session(s) utilized by the service also become fail-safe. More details on this will be provided by other metro developers. Specifically checkout Jiandong's blog page.
Support for Signing Tokens not in message via STR-Transform
Prior to Metro 2.1, the WS-SecurityPolicy assertion <sp:ProtectTokens/> would fail to include a signature over the Token when the token is not physically present in the message (IncludeTokenPolicy==Never). We have tried to fix this in Metro 2.1. The WS-SecurityPolicy spec says the following about ProtectTokens assertion :
- In the case of SymmetricBinding, the main signature MUST cover the Signature Token
- In the case of AsymmetricBinding, the main signature MUST cover Initiator Token
- Endorsing signature MUST also cover the supporting token.
When the token is not present in the message then an STR-Transform is used to reference the token. Note that when token in question is a SAML token and it is not present in the message then Metro would still fail to protect the token.
Protecting the token (binding it to the message signature) is important to prevent a substitution attack.
WS-I BSP 1.1 and RSP 1.0 Compliance
The Metro 2.1 release was tested for WS-I BSP (Basic Security Profile 1.1) and RSP (Reliable Secure Profile 1.0) compliance. There was also an extensive interoperability testing done with the WCF Stack and a Metro to WCF interoperability white-paper was produced.
Support for RSA-SHA256 and higher bit SignatureAlgorithm
The W3C working draft of XML Signature Syntax and Processing version 1.1 recommends the use of SHA-256 over SHA-1 because recent advances in cryptanalysis have cast doubt on the long-term collision resistance of SHA-1. Metro 2.1 adds experimental support for this using a proprietary WS-SecurityPolicy extension to the <sp:AlgorithmSuite/> assertion. More details on this can be found in the following post.
WebServices Interoperability with other Oracle Products
A few important Security Scenarios which make use of X509Token, SAML, UsernameToken and PolicyAlternatives were identified and tested using Metro Client and WebService built using Oracle(11g) SOASuite, OSB, ADF and WebLogic Server respectively. Reverse testing (as applicable) involving a Metro Service and clients built using the mentioned Oracle Products was also done. Successful Interoperability was established and issues found during the testing were fixed.