What are the requirements for WS-Security support and how should they be implemented?

[jeffdelong]

I have started this discussion in support of two JIRAs

https://jira.jboss.org/jira/browse/RIFTSAW-75

https://jira.jboss.org/jira/browse/RIFTSAW-190

In these JIRAs Garys says:

here are three usecases - enabling BPEL processes to be secure, allowing BPEL processes to invoke secure web services, and finally to propagate security context through the BPEL process to invoked services.

and in RIFTSAW-190 I describe a potential solution based on ESB and PicketLInk for certain aspects of the first and third requirement.

I think it is worthwhile to further analyze the requirements listed above and then discuss potential solutions.

The general requirements for security include: authentication, authorization, data confidentiality, and data integrity and non-repudiation. In an SOA security is best provided though a combination of message-level security, security as a service, and policy-based security. For individual services this approach relieves the service of the responsibility for providing security, instead relying on the security service. In general Web services address security requirements:

• authentication - supported by various authentication tokens in the SOAP Header. These tokens can be validated by an identity management component of a security service, and augmented with additional information about the authenticated principal (e.g. roles).
• authorization - supported through role information associated with the authenticated principal. Enforced external to the consumed service based on some declarative policy.
• data confidentiality - supported through message level encryption where encryption information is added to SOAP Header elements.
• data integrity and non-repudiation - supported through message signatures added to SOAP Header and perhaps message encryption.

Requirement 1: Enable BPEL processes to be secure. A BPEL process is a Web service, so this is really equivalent to enabling the Web service that exposes the BPEL process to be secured. I don't think this adds any additional requirements to Riftsaw per se, as security capabilities can be provided by the deployment environment of the BPEL process Web service

Requirement 2: Allowing BPEL processes to invoke secure Web services. Which of the following security features would be supported.

• authentication - the service being consumed requires some form of authentication information per WS-Security. There are several ways this is supported in WS-Security. Is the requirement to support all of these or some subset?
• authorization - is enforced on the invoked service end based on authenticated principal information.
• data confidentiality - would require outgoing message encryption and response message de-crption. How would this be specified? Would we support encryption of different parts of the message?
• data integrity and non-repudiation - would require outgoing message signing? How would this be specified?

Requirement 3: Propagate security context through the BPEL process to invoked services. Which of the following security requirements would be supported:

• authentication - the service being consumed requires some form of authentication information per WS-Security. The initial consumer of the process service has been authenticated, so the requirement is to pass the authenticated principal information from in request activity to each of the invoke activities where it is required. This implies that the process designer can map SOAP header elements from the incoming message variable to the outgoing message variable.
• authorization - is enforced on the invoked service end based on authenticated principal information. It is possible that the roles associated with the principal having consumed the process service are not sufficient to access the invoked service, however it is allowed for the process to access the invoked service. In this scenario a new role must be added to the authenticated principal.
• data confidentiality - is implemented through message level security (encryption). This would require outgoing message encryption and response message de-crption as in 2 above. I don't think it makes sense to treat a BPEL process as an intermediary and keep the message data encrypted as it passes through the BPEL engine. BPEL implies access to message data for branching, correlation, etc.
• data integrity and non-repudiation - would require the mapping of message signatures in the SOAP header elements from the incoming message variable to the outgoing message variable. Is this required?

[objectiser]

Hi Jeff

Thanks for starting this thread. I am currently in the investigation stage on this issue, so will answer what I can - but it would be good to get input from others, especially from potential users on how they would like this to work.

Although RiftSaw makes use of JAX-WS APIs, unfortunately configuration of the security features of jax-ws compliant WS stacks is not standardised. Therefore we are currently focusing on configuration of the CXF stack.

Requirement 2: Allowing BPEL processes to invoke secure Web services. Which of the following security features would be supported.

• authentication - the service being consumed requires some form of authentication information per WS-Security. There are several ways this is supported in WS-Security. Is the requirement to support all of these or some subset?
• authorization - is enforced on the invoked service end based on authenticated principal information.
• data confidentiality - would require outgoing message encryption and response message de-crption. How would this be specified? Would we support encryption of different parts of the message?
• data integrity and non-repudiation - would require outgoing message signing? How would this be specified?

On Alessio's recommendation, the approach we are likely to take is to require most WS-Security related configuration to be defined as policies in the WSDL. However some configuration information will still need to be provided.

So in terms of the capabilities that could be supported - this would be based on what jbossws-cxf supports via policies.

Requirement 3: Propagate security context through the BPEL process to invoked services. Which of the following security requirements would be supported:

I think it only makes sense to propagate authentication information from the inbound to outbound messages by transfering the details via the message SOAP headers. Encrypted messages definitely cannot be handled through the process. I don't think it would make sense to carry signature information through, and it would only be possible if essentially the same message was being transferred through without modification, as otherwise the signature is meaningless, so this would be a very specific usecase.

Regards

Gary

[the_olo]

A particular, practical and non trivial use case that we're concerned with, and will most likely open a service request through JBoss developer support if it won't be trivially implementable in Riftsaw, is using information extracted from parsing X.509 certificate fields (subjectName) in our BPEL process as variables.

To be concrete, we'd like to make a BPEL service exposed in the following way:

1. The client/process initiator invokes the BPEL process through a WS-Security enabled web service. Signature, Encryption are mandatory and Timestamp is optional but always provided from our side.
2. The client party authenticates itself through the usage of WS-Security Signature by means of its X.509 certificate. The certificate is not contained in the message, but rather referenced by its subjectKeyIdentifier, which identifies the certificate to look for in the local server side KeyStore/truststore - this is a very important detail, the messages don't carry the X.509 certificate with them - server has all the possible client certificates in its store.
3. The WS-Security handler searches its local truststore for a certificate with a matching subjectKeyIdentifier, then uses that certificate to verify the signature on incoming message, parse it and extract client's identifier to inject into a message variable, and encrypt the response message when it will be ready to be sent back.
4. Certificate validation or signature verification failures prevent the service from being invoked. Obviously, message decryption failures likewise.
5. From the client's X.509 certificate, the subjectName field is extracted, parsed and individual RDN components are taken for processing to determine client's identifier.
6. The client's identifier (principal name, or whatever term should be the most appropriate) is determined by looking for values of "CN" and "O" subjectName's RDN components. Only values that consist of exactly from 2 to 4 alpha characters are accepted. "CN" has a precedence over "O" regardless of their order as RDN components in the subjectName - if both seem like valid values, the value of "CN" is chosen. If the identifier cannot be determined this way, the logic falls back to using the certificate's alias in the local keystore as the identifier. For example:
   • A certificate found in the keystore for the incoming message's subjectKeyIdentifier has a keystore alias of "rhat", and a subjectName of "C=US,ST=NC,O=Red Hat,OU=JB,CN=JBoss division". From these 5 subjectName RDN components, none yields a valid identifier (neither CN nor O contain exactly 2-4 alphas, others do but aren't of required attribute type). Therefore, as a fall back measure, the alias of the certificate in the keystore file ("rhat") is taken as the client identifier.
   • A certificate found in the keystore for the incoming message's subjectKeyIdentifier has a keystore alias of "rhjb", and a subjectName of "C=US,ST=NC,O=JBOS,OU=JB,CN=JBAS". From these 5 subjectName RDN components, both "O" and "CN" yield a valid value, but CN takes precedence. Therefore, "JBAS" is taken as the client identifier.
7. The determined client identifier is injected into the decrypted message as a new element (BPEL variable  with a configured name) before being passed to the BPEL engine for consuming.
8. The BPEL process uses the variable value during execution of its business logic.
9. The intent of all of the above is that the certificate used for message signing is used to identify the calling party and this information is seamlessly integrated into the BPEL process execution.

Additional requirements:

1. Local keystore/truststore of the service should be hot-deployable without any service interruption:
   • When a new keystore (containing the service's private key and certificate) or truststore (containing clients' certificates) file for the service is deployed, the process occurs parallel to serving requests using the old keystore/truststore files.
   • When the new keystore/truststore is loaded, an atomic switch is performed to the new keystore/truststore so that new requests are processed using it without any drops or delays
2. The keystore and truststore file locations should be relative to web application and server's classpath. It should be possible to place them not only in the .war in WEB-INF directory, but also in the file system, and reference both by absolute paths (e.g. /opt/jboss/server/default/conf/appname/keystore.jks) and relatively to the classpath (e.g. JBOSS_CLASSPATH=/opt/jboss/server/default/conf/appname, keystore file configured: keystore.jks)
3. Support for hardware tokens/hsm through different JCA providers (including Sun PKCS#11 provider) in place of keystores and truststores should be present and should be included in integration tests of the project (simple smartcard-based tokens are very cheap nowadays).

Nice to have:

1. In memory cache that would map subjectKeyIdentifier values to keystore entries so that there's no need to repeat searches through all the certs in the keystore when looking for a matching certificate for the given key identifier.
2. Likewise for all the other WS-Security token reference key identifiers that reference a token outside of the message (currently: only Issuer and serial number)

As to which components and layers should optimally realize which tasks, I'm not quite sure how that would fit into the planned Riftsaw architecture with respect to WS-Security (this is the point of this discussion, I suppose).

Some loose ideas  (I may be way off base here):

1. Use SAML and STS to extract information from the X.509 certificate (Is it possible to extract subjectName RDN components using this approach? Can it access certificate that's extracted from a local keystore and not embedded in the message?)
2. Alternatively, use WS-SecurityPolicy and /sp:X509Token/wst:Claims or /sp:X509Token/wsp:Policy for that?
3. Alternatively, use some CXF's class (like org.apache.cxf.ws.security.wss4j.SimpleSubjectCreatingInterceptor) or its derivative for that?