Description
The SOA Security Pattern addresses security along four dimensions:
- Authentication – It must be possible for the service provider to ascertain the identity of the service requester.
- Authorization – The service provider must be able to determine whether the requester has the appropriate rights to invoke the service.
- Message Confidentiality – Message contents must only be visible to the intended recipient.
- Message Integrity – It must be possible to guarantee that a message has not been altered or tampered with in transport between the service consumer and the service provider.
This pattern is generally applicable in cases where the Enterprise Service Bus (ESB) is used, but should be followed when message security is required and the ESB is not being used.
The security information related to the message payload is typically contained in the message header as shown in the figure. The security header for the message contains a security token, a digital signature when necessary, and information related to the encryption of the message if the message has been encrypted. Authentication is supported through the use of client-side x.509 certificates, username and password, and Security Assertion Markup Language (SAML) certificates. These are the profiles currently supported by TIBCO. Message confidentiality can be guaranteed at the transport layer via Secure Sockets Layer (SSL) or within individual messages. Encryption at the message level ensures confidentiality across multiple “hops” in the integration infrastructure. Message integrity can be guaranteed through signing using digital certificates. Time stamps are used to prevent replay attacks.
Please view the Service-Oriented Architecture (SOA) Security Pattern below:
Diagram
Benefits
- Ensures integrity and confidentiality are maintained. User authentication and authorization are facilitated.
- Allows built-in ESB mechanisms to be fully leveraged while still remaining consistent with open standards.
Limitations
- Current web services standards do not include security information within the core interface definition language, Web Services Description Language (WSDL). Security information must be provided “out of band”.
- X.509 certificates may be required to support digital signatures, authentication, and message encryption.
- Granular authorization must still be handled within the context of the service being invoked.
- The service implementation may need to have knowledge of the user identity and manage permissions internally.
- Message level security is not provided for non-SOAP services by the ESB.
Recommended Usage
Specific requirements for authentication, authorization, confidentiality and integrity should be established on a case by case basis. When requirements are determined, consistent approaches as described above in the pattern should be used.
Not all components of the pattern must be used in all cases. For example, in some cases, transport level encryption may be adequate. In other cases, authentication using a username may be adequate and encryption may not be necessary.
There will be cases where no security will be required at all. An example would be a web service offering information currently available to the general public through NIH’s Computer Retrieval of Information on Scientific Projects (CRISP) system.
Implementers are encouraged to contact NIH Enterprise Architecture team for specific guidance in implementing security for SOA services.
Time Table
This architecture definition approved on:
May 24, 2006
The next review is scheduled in:
TBD
