I have started this discussion in support of two JIRAs
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?