Ok. Got some time to upload the images and the listings. There are some documents which are too lengthy and I don't intend to upload it. Please email me if you need it. They are examples. Oh sure! you could download pleanty of them. But if you don't want to run after searches, let me know and here you have these below.
1. Code listings - Zip file
2. WSSE Spec. Case studies
3. SSL/Implementation-step by step.
4. SAML Document
5. How to compose a SOAP for encryption.
Webservice Security Part II
Many standards exist today for implementing webservices security. With standards like WS-Security, XML Signatures, XML Encryption and SAML, it could be a little difficult to decide which way to go, when applications collaborate through webservices.
If we have to just secure a service call, all we need to do is to just implement SSL. Call through HTTPS and client is secured against information being sent across, you know to whom it is being sent etc.
If we need to secure both client and server, we simply implement a two way SSL. By doing so, everything which goes to and fro from client to server and back are all encrypted.
Yes! The SOAP message is now encrypted and is passed through this secured tunnel.
A few questions to ask:
Are service calls completely secured?
Why should I go for any other type of mechanisms when SSL exists?
What is WSSE and why should I implement this?
…More
Like we had discussed in part 1, a webservice call cannot be considered completely secured if we just implement two way secured mechanisms. Sender becomes a trusted party for a receiver and vice versa, but what if the senders receives messages from a third party and there are no secured mechanisms implemented between them? In order to provide total security we need to oversee the following:-
Let there be authentication and authorization mechanisms implemented.
Let there be access control systems in place. This will get down, to a level where system gives access to a specific business processes, based on roles. Yes! This is business centric. Remember, we are talking about securing webservices totally. How can you NOT think of having control over your services? We will discuss this in detail later, the reason.
Let there be message integrity, in other words, message repudiation.
Let encryption methods be standardized.
Let there be prevention methods in place to address DOS attacks.
Figure showing two way SSL implemented:
Drawbacks to the this model.
In the this model, one thing is made sure, the security of the user information, in that nobody can intercept the flow and if at all, they would not be able to sniff out any messages. Data packets would not make any sense to the sniffer. The big question is, are we safe yet? The answer to the question is NO.
Why is it that it is not safe? We are still not sure if the packets contain the appropriate data. A sinffer would have intercepted the messages and would have tampered with the message. What would have been left to flow would have been a corrupted message and so it is still not safe to make a call with just SSL in a two way service call. What else can be done?
A service call is pretty much a SOAP packet. When the envelope is sent to a client, the soap message is embedded inside the packet. We suddenly realize, what is required, is an XML Security.
A network level firewall is deployed at the entry point of a private network . It does the following routines
Monitors all incoming traffic;
Validates the identity of application
Authenticates users based on their identities, which can be the network addresses of service requesters or security tokens;
Checks security and business policies to filter access requests and verify whether the service requester has the right to access the intended resource; and
Provides for encrypted messages so that confidential business information can be sent across the untrusted Internet privately
Although we have the infrastructure in place for all of the above, because webservices send and receive SOAP packets which are XML documents, we still need to fabricate a different secure mechanism to incorporate security for these packets.
XML encryption for Web Services
It is important to know at a high level , features of some of the security protocols from W3C and OASIS.
The XML Signature specification is a joint effort of W3C and IETF. The idea is to provide data integrity and authentication (both message and signer authentication) features, packeted inside XML format.
W3C's XML Encryption specification addresses the issue of data confidentiality using encryption techniques. Encrypted data is packeted inside XML tags defined by the XML Encryption specification.
WS-Security from OASIS defines the mechanism for including integrity, confidentiality, and single message authentication features within a SOAP message. WS-Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message.
Security Assertion Markup Language (SAML) from OASIS provides a means for partner applications to share user authentication and authorization information. This is essentially the single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. In the absence of any standard protocol on sharing authentication information, vendors normally use cookies in HTTP communication to implement SSO. With the advent of SAML, this same data can be wrapped inside XML in a standard way, so that cookies are not needed and interoperable SSO can be achieved. Cookies are considered sometimes even not as safe as it should be.
Check out the following common wellheard of sites.
XML Signature(http://www.w3.org/Signature/,
XML Encryption (http://www.w3.org/Encryption/2001/)
WS Security (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss,
SAML http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security)
There are various kinds of XML-based security standards, XML Signatures, XML Encryption and Web Services Security -- which offer user authentication, message integrity and confidentiality features in SOAP communications.
Please take a note of the red texts above. Those are the important factors in a webservice call. Message repudiation is the biggest challenge in attaining security on a webservice call.
In a world we live in, we hold ‘keys’ to many rooms, boxes, solutions and now for software descriptions.
Asymmetric cryptography is a method in which you hold the private key and the public key is shared. In that, a message is decrypted by the combination of the private and public keys. As long as you hold the private key within yourselves, messages are quite safe.
Symmetric cryptography is a mechanism in which you share the same key for encryption and decryption. Due to overheads in maintaining a Asymmetric cryptographic encryption and decryption for message processing, , it is used often, for sharing the secret shared key for a symmetric cryptography.
With the above said, we will try to understand the need for Digital Signatures. Apart from the above methods of verifying the integrity of the message, concepts called message digest are utilized. Message digests works in a way wherein the sending party sends the message and a digest value along with it. The digest value can be used to verify if the message has been altered or not. The digest value depends upon the data. On receipt of a message, digest value is computed and alteration detected. A problem with this is, it is difficult to know if the data by itself is tampered or not. Since the digest is computed from the data and is send along with the message itself, if both are tampered, it will be difficult to detect.
An application of digital signatures comes here. Along with the message if a digital signature is sent, the receiving party can validate the signature by decrypting it against public key. Once the verification passes, the "message digest" verification, the digital signature is verified. If both passes, we can justify that the communication has been safe. We then confirm that the request is coming from a genuine owner and that the message by itself has not been tampered. Common certificates can be used for digital signatures. This holds the information of the identity of the authority and public key of the owner. The CA will also sign using its private key. This can be used to check for integrity of the certificate.
What we discussed above so far has now been much more standardized. With XML driven requests, the same is being discussed in terms of XML. Thus XMLSignatures are pretty much nothing but utilization of the above using XML.
This gives rise to an interesting subject. The need for XML’s to be processed inside the firewall. Because SOAP message come in as a part of a service call, it is imperative for security reasons to have a processing type of the above nature inside the firewall. Deployment of webservices is a different subject. I would like to explore that next. But at a high level, this is also important.
Thus a typical request will now go through XML Firewall. Here it gets checked with message integrity, passing which user authentication checks are done and business partner validations done, after which the message is passed on to the SOAP server.
XML Digital signature standards are pretty flexible. It can be used anywhere within the SOAP message.
A few examples follows:-
http://riverlog.com/SOA/Listings
WSS relies on XMLDS and XML encryption for low level details and defines a higher-level syntax to wrap security information inside SOAP messages.
WSS describes a mechanism for securely exchanging SOAP messages. It provides the following three main security features:
Message Integrity
User Authentication
Confidentiality
Together, a complete secured service call is made. This obviously does not complete the description on security. Things like SAML, X509 Certificates etc exist.
How secured are we? It could only be imagined the number of attackers sitting beneath the lower grounds of dungeons trying to hack into systems to steal information. But massive attacks on webservie based applications, are yet to begin. They are not there yet. As more standards are being built, many types of implementation exist, thieves are not making such attempts. Lack of that knowledge prevents them from attempting break-in. But we are not so far.
As it is said, the idea is to make a strong feeling, a feeling of being secured!
