WS stack technologies review

Recently I started to invest time in learning of web services.
I have learnt the basics of WSDL 1.1.
Now I'm trying to understand other aspects of WS. Where are a lot of WS-* technologies. Some of them are obsolete, some are not supported. So the aim of this post is to understand the widely adopted specifications and the possible use cases for them.

WS-Addressing

WS-Addressing (http://www.w3.org/TR/ws-addr-core/) provides transport-neutral mechanisms to address Web services and messages. The transport-neutrality is achieved by normalizing the information typically shared between transport protocols and messaging systems.

Use cases

• Transport neutrality. This allows to include the addressing information into the SOAP header.
• Asynchronous invocation. You can send the request and receive the answer later at some time.
• Conversation. There are headers which allows to relate messages by their id.
• Distributed processing. You can define where to return faults and responses separatly. 

WS-Security 

WS-Security describes three main mechanisms:

• How to sign SOAP messages to assure integrity. Signed messages also provide non-repudiation.
• How to encrypt SOAP messages to assure confidentiality.
• How to attach security tokens to ascertain the sender's identity.
  

The specification allows a variety of signature formats, encryption algorithms and multiple trust domains, and is open to various security token models, such as:

• X.509 certificates,
• Kerberos tickets,
• UserID/Password credentials,
• SAML Assertions, and
• custom-defined tokens.
  

The token formats and semantics are defined in the associated profile documents.

Use cases

• Confidentiality. Thanks to encryption message can be seen only by intended recipient.
• Integrity. One can assure the integrity by signing the document.
• Non-repudiation. If you sign the document, you cannot decline as it is author.
• Protocol agnostic. Security doesn't imply limitations on the protocol binding.

• The specification for inclusive XMLcanonicalization is available at http://www.
  w3.org/TR/xml-c14n.
• The specification for exclusive XMLcanonicalization is available at http://
  www.w3.org/TR/xml-exc-c14n/.
• Constraints on the use of XML as a namespace prefix are described in the XML
  Namespaces specification at http://www.w3.org/TR/xml-names11/#xmlReserved.
• The specification for xml:idis available at http://www.w3.org/TR/xml-id/.
• "XML-Signature Syntax and Processing," a W3CRecommendation, is available
  at http://www.w3.org/TR/xmldsig-core/.

Security as a service.

We want to address the challenge of deploying, managing, and evolving security enforcement mechanisms across a large number of services.

Security service use cases:
1 Destination endpoint invokes security service out-of-band. That is a service it self calls the security service. Technologies: SAML and\or WS-Trust.
Pros: Source endpoint doesn't need to know about the security service and how to interact with it.
Cons: Source endpoint needs to reveal it credentials to the destination endpoint. Destination endpoint can steal that credentials.

2 Source endpoint invokes security service out-of-band. The client calls the security service.
Technologies: SAML and\or WS-Trust.
Pros: Scales better because the service has no additional burden of verifying the credentials.
Cons: Increases the client complexity. The security context is getting bigger when number of attributes increase.

3 Both endpoints invoke security service out-of-band. Client and service both call the security service.
Technologies: SAML and\or WS-Trust.
Pros: Only necessary information is passed.
Cons: Impose programming burden on both endpoints.

4 Messages are explicitly routed via the security service by the source end-point or by a previous intermediary in the message path.
Technologies: WS-Addressing and SAML.
Pros: Security service can offer more functionality.
Cons: Add client complexity.

5 A smart network device automatically routes messages via the security service

Messages are routed explicitly through the security service.
Technologies: WS-Addressing and SAML.
Pros: Endpoints need not be burdened with the task of routing messages to security service.
Cons: Need device in order to implement this use case.

SAML can communicate the security context.
SAML statements:
 ■ Authentication statement
■ Attribute statement
■ Authorization decision statement

It seems that routing all the requests to the custom security service imposes the transmitting of unnecessary amount of payload to make a security check. That's why there is a standard called WS-Trust.

WS-Trust

WS-Trust extends the WS-Security specification to allow issuing, renewing, and validation of security tokens. A lot of what WS-Trust does centers around the use of a "Security Token Service", or STS.

The STS is contacted to obtain security tokens that are used to create messages to talk to the services. The primary use of the STS is to acquire SAML tokens used to talk to the service. Why is this interesting?

When using "straight" WS-Security, the client and server need to have keys exchanged in advance. If the client and server are both in the same security domain, that isn't usually a problem, but for larger, complex applications spanning multiple domains, that can be a burden. Also, if multiple services require the same security credentials, updating all the services when those credentials change can by a major operation.

WS-Trust solves this by using security tokens that are obtained from a trusted Security Token Service. A client authenticates itself with the STS based on policies and requirements defined by the STS. The STS then provides a security token (example: a SAML token) that the client then uses to talk to the target service. The service can validate that token to make sure it really came from the trusted STS.

The tokens for example can be SAML assertions, Kerberos ticket, key, certificate.
Scenarios for using WS-Trust:

1. The client requests a token to access web service from STS.
2. The intermediary invokes STS to do authentication or authorization.
3. The service endpoint invokes STS to do authentication or authorization.
4. The intermediary or target service invokes STS to exchange one security token for another. For example cookie for LTPA token.

If you are going to request SAML assertions then you can use SAML protocol.

WS-Policy

Allows to define the basic syntax for expressing policies.
Provides an algorithm for comaring two policies.

WS-MetadataExchange

Defines how to query metadata such as XSD, WSDL, WS-Policy.

WS-PolicyAttachment

Defines how policies can be attached to WSDL definitions and UDDI entries.

WS-SecurityPolicy  

WS-SecurityPolicy standardizes assertions related to usage of WS-Security, WS-Trust, WS-SecureConversation in WS-Policy documents.  WS-SecurityPolicy is not a panacea. For specifying the details of security(like authorization) one can use XACML (eXtensible Access Control Markup Language).

That was a long journey. What i have i practically did is using of WS-Security with signing. What I want to try is WSO2 Security and Identity Gateway (http://wso2.com/solutions/security-and-identity-gateway/) to solve real tasks.