Hello and good week to all!
These days I am starting to publish here (in my blog ofcourse) a series of articles that discusses with Web Serivces and the most important issue - Security over Web Services (using Microsoft technology ofcourse), because it is quite simple to write a web service that receives/retrieves data and 'do you thing...', but the complexity comes when you want to secure this data that runs over non-secured protocols or web-lines.
This article assumes that you are familier with web services, its porpuse and its implementation and assimilations, if not, you should read some basic tutorials before you start to read this article. (You can fine general example here).
Introduction
WS-SecurityProtocol defines all web services expansion security topics. Its goal is to let you build and use SOAP messages exchange in secured way. This term is quite flexble and it designed in a specific way in order to constitute the base of building a secured Web Service by the different security models like: SSL, Kerberos, PKI.
WS-SecurityProtocol supplies a full support for large number of security tokens, trusted domains, signature formats and encryption technologies.
This component supplies 3 basic mechanisms: Message Confindentiality, Message Integrity, Security Token Propagation. These mechanisms, each one by it own, doesn't supplies perfect security solution, therefore in actual fact, WS-SecurityProtocol builds a block that uses a combination of all there mechanisms and different enhancements to supply a perfect sucurity solution
Main Facts
Before I start explaining and showing the protocol's structure, I want to stand on the basic definitions and terms this protocol is uses:
- Claim - the client's claim (like: name, identity, key, group, rights and more...)
- Security Token - represent a set of tokens.
- Signed Security Token - this is a claimed and encrypted by a specific authority (like: Kerberos ticket or X.509 certificate) security token.
- Proof-of-possession - information that used by a specific "proof process" in purpose to describe the sender data.
- Integrity - a process that comes to note that the sent data hasn't changed while sending the message.
- Confidentiality - a process that comes to ensure that the data is protected and just specific authorized 'players' are allowed to watch it.
- Digest - an encrypted sum of the data sent stream.
- Signature - this is an encrypted communication between the Proof-of-possession and the digest. This action creates a symetric key and public signatures.
- Attachment - this is the physical data that is transfered using the SOAP messages, but is not a part of the SOAP envelop.
We want to ensure that the SOAP message is encrypted properly to avoid dangers, like:
- The message could be readen and be changed by malicious user.
- Malicious user can send fake message through the Web Service and by that to get secret information.
Message Security Model
The WS-SecurityProtocol works under the Message Security Model, that comes to prevent such cases like mentioned above. Its behavior is:
The Security Token declares on Claims and Signatures, this mechanism supplies a proof to the knowledge of the sender (in simple words, the data that the sender holds). In addition, the Signature can bind itself with the Claims in the Security Token (in assumption the token is secured).
Claim can be supported (or not) by "secured authority", which is a set of claims, which encrypted or digitally signed by this authority is usually represented by Signed Security Tokens. An example to Signed Security Token set is X.509 Certificate - which by this set of claims, the binding is executed between the client identity and the the public key.
Claim that is not supported by any "secured authority", can be secured only when the connection (binding) between the sender and the receiver is secured (secured line, like SSL etc...), for an example, they can agree on a specific message name that is accepted by both of them and by that only they will know that the message is meant for them (because they are both will look forward to get the same name).
Another type of non-secured claim (which is not supported by any "secured authority") called proof-of-possesion. As I descibed earlier, this term confirms that the user has "pieces" of knowledge that diagnosed by the other 'players' which related to it. For an example, lets take a look of username/password security token, the proof-of-possession here, combines another security token in order to confirm the sender's claim. I need to note here, that Digital integrity (see above if you already forgot) for a message can be used as a proof-of-possession, but in theis case it will not considered as a security token.
Message Protection
Another model that comes to prevent such cases as mentioned above (remember...?).
This model claims that all the messages that are being sent, supposed to be encrypted in order to not be negatively affected by hostile factors. The Integrity based message is supplied by leverage of an XML signature with security tokens, in order to notice that the messages has been sent with no data changes of bad influences. This mechanism supports many signatures and players.
A confidentiality (see above for a definition), based message, uses XML encryption with secutity tokens to ensure that the message's parts will be confidential.
In order to supply the the maximum security to the SOAP message, that we'll want to send, there is a need to build the XML file that includes all the filters and headers definitions.
The structure of the XML file includes the <Security> tag, which symbolizes the security definitions. Under this tag it is possible to define all the information about the message security issue.
An XML file cannot hold more that one security tag, this in purpose to allow that each tag (security XML) will taget to other destination. This tag and all its data under, represents the signature steps and the encryption type that the sender used with to send the message.
A typical WS-SecurityProtocol example:
Line 001 and 002, describes the SOAP envelope. Line 003 opens the headers definitions that describes the message. Line 004 to 008, describes the sending message type, the source and destination.
Line 009, open the Security's filters definitions. This label defines the security definitions that the receiver need to be up to (in order to watch the message ofcourse). This header label is closed in line 029.
Lines 010 to 012, describes the security token that message uses, here the usage is username token. (Here the assumption is that the password is well known by the service, and by that, only username is being sent).
Lines 013 to 028 defines the digital signature. By this example, the signature is based on the key that generated from the sender password. Lines 014 to 021, explains the digital signature. Line 015 defines how to normilize the sent information.
Lines 017 to 020, chooses the elements we want to signature. In this example (by line 017), we can see that the body is digitally signed (<s:Body> label, which you can see in line 031).
Line 022, holds tha signature value that derivated from the encrypted information. Lines 023 to 027, holds an information about the security token location, which combined with the signature. In more explicit, lines 024 - 025, defines that this token is located in a specific URL address.
Line 031 to 033 holds the message body.
That it for now. More tutorials at:
Comments will be appriciated...