This final part of the article on SOA security deals about technology involved in securing WSOA (Web SOA)
Secure interaction in the case of WSOA is about security of SOAP messages. SOAP does not contain any means for authentication (such as context or passing of credentials). There are three common ways to secure messages between services.
1. HTTP with TLS (HTTPS)
2. XML encryption and XML signature
3. Security Tokens
These three will be described in the following sections.
HTTP with TLS (HTTPS)
HTTPS is the common name for a secure HTTP connection. HTTPS is HTTP run over a TLS connection (TLS used to be SSL, hence the name HTTPS). TLS creates sort of tunnel between a client and a server. Data send through this tunnel is encrypted. Thereby also the server side is authenticated. In some cases two-way TLS is used, whereby both the server and client are authenticated. Since TLS is a transport level protocol, it does not protect individual messages, but only the transportation of these messages. Messages (such as XML documents) are not secure after they leave the TLS tunnel.
XML Digital Signature and XML Encryption
XML signature (XML-SIG) is a W3C recommended standard for creating XML-based digital signatures for any type of data (including XML). The data is signed by using the sender’s digital signature. The signature and signed data can be part of the data document, or it can be located on a remote URI. The digital signature can use any available signature algorithm. The signature itself is in the form of a digest that in turn can also be encrypted with the receiver’s public key. XML Signatures provide integrity, message authentication, and signer authentication.
XML Encryption (XML-ENC) is a W3C recommended standard that defines the process and format to encrypt data and represent the result in XML. XML-ENC supports the encryption of an entire XML document or just a part of it. There are three different ways to encrypt the XML data:
1. Symmetric key.
2. Asymmetric key.
3. Via third party certificate (such as X.509).
When data is send (encrypted), confidentiality of data is preserved.
Security Tokens
A Web service can require an entity to provide proof of claims that it makes. A claim is a statement that is made by an entity itself or by another entity concerning a specific entity. Security tokens are a collection of claims. Security tokens are used in the header of a SOAP message. There are three different types of security tokens: username, binary, and XML security tokens.
1. Username token
The username token is the most basic security token. The username is represented in an unsigned XML description. Because it is just in plain text, this is not the most safe security token available.
2. Binary security tokens
X.509 digital certificates and Kerberos are binary security tokens that are encoded as binary and represented in XML. This type of security token can be integrated with existing solutions that manage identities (such as PKI, LDAP and Active Directory). This allows for a flexible infrastructure because it allows propagation of identity credentials through several systems.
3. XML security tokens (SAML)
SAML can define authorization and authentication statements, and signed messaging of XML. When SAML is used it presumes that some third party service will assert the correctness of the claims made within the SAML. To be able to do so SAML includes the notion of three different types of assertions, which are issued by assertion providers. The three assertions are: authentication, authorization and attributes. An entity can request a security assertion from an assertion provider. The assertion provider will provide the entity with an assertion that contains a timestamp, an assertion ID, and the subject of the assertion. For example, an authentication assertion is a representation by a third party that a specific entity has been authenticated.
The above article gives a glimpse of how security can be built into SOA and provides readers a road map for in-depth research on SOA security.