Advanced Topics
on WEB services
This section will
discuss some of the well-known topics of WEB based systems to compare the
strengths with other systems that support following features:
Security
SOAP is designed to slip through firewalls as HTTP. There is no doubt
that this is a design goal.
Security is needed
for any WEB based system especially for WEB services where the preferred
communications is over HTTP and XML. Current WEB security infrastructure (SSL)
is too secure for WEB service implementations.
SSL: Secure Socket Layer is
layer is a proven technology for secure communications between a WEB client and
server. HTTPS is s higher-level protocol using SSL as a layer. SSL provides
confidentiality, through encryption, and authentication, using X.509 digital
certificates, for HTTP traffic. SSL may also be used to secure WEB services.
Why is SSL not
enough? Although SOAP is often sent
over HTTP ("bound to HTTP" in the jargon), it does not necessarily
have to be. SOAP is independent of the underlying communications layers. SOAP
messages can also be sent over e-mail—that is, Simple Mail Transfer Protocol
(SMTP), or FTP—just as easily. A single SOAP message can traverse a number of
different transports in the context of one transaction—for example, using HTTP
for the first leg, then SMTP for the next leg, and so on. SSL, as we've seen,
provides confidentiality and authentication for a single point-to-point HTTP
session, but it doesn't provide an audit trail that guarantees that the session
occurred.
Current SOAP
specification doesn’t cover Security. New proposal is underway for XML Web
Services Security Language (WS-Security).
The new solution
ensures that even if the SOAP message is sent over an insecure transport, or if
it traverses a number of legs through un-trusted servers, it remains secure. We
can compare SOAP to e-mail between applications; the analogy with e-mail
continues to hold here. If an e-mail message is being sent across the Internet,
it isn't sufficient to simply encrypt the links between e-mail servers. The
e-mail message itself must be encrypted. So it is with SOAP messages. The
World Wide Web Consortium (W3C) and the Organization for the Advancement of
Structured Information Standards (OASIS) have developed a number of new
specifications for this purpose. XML Signature and XML Encryption describe how
integrity and confidentiality are enforced for XML documents, while WS-Security
applies these XML security technologies to SOAP messages.
The .Net Common
Language Runtime (CLR) includes implementations of XML Signature, XML
Encryption, and WS-Security. This functionality is available to programmers
writing .Net-hosted Web services. Similarly, the J2EE environment contains
security functionality that is available to developers.
WS-Security provides
enhancements to SOAP messaging consisting of three capabilities: credential
transfer, message integrity, and message confidentiality. The WS-Security
specification defines a new SOAP header for security implementation.
Authentication
WS-Security provides
for an infinite number of ways to validate a user. The specification addresses
three methods from that infinite number:
Username/Password
One of the most
common ways to pass around caller credentials is to use a username and password
combination. This is a technique used in HTTP Basic and Digest authentication.
To pass user credentials in this manner, WS-Security has defined the UsernameToken
element. Schema for the element is as follows:
The UsernameToken
element is defined in WS-Security to provide a means for doing basic
username/password validation. If you have experience with HTTP, then you can
consider this to be similar to Basic Authentication. WS-Security does provide
some variation through three forms of the UsernameToken element. The
different forms are shown here:
<!-- No Password --><UsernameToken> <Username>Bob</Username></UsernameToken> <!-- Clear Text Password --><UsernameToken> <Username>Bob</Username> <Password Type="wsse:PasswordText">Opensezme</Password></UsernameToken> <!-- Digest: SHA1 hash of base64-encoded Password --><UsernameToken> <Username>Bob</Username> <Password Type="wsse:PasswordDigest"> QSMAKo67+vzYnU9TcMSqOFXy14U= </Password></UsernameToken>
The first form does
not include a password, so consider this an option for situations where some
other mechanism authenticates the individual and the username token is used
only for identification. The second option includes the clear text password. As
you might expect, the authentication process on the other end would involve
checking some sort of database of valid usernames and passwords to see if there
is a match. The third option sends a digest of the password instead of a clear
text password. The good news about this approach is that the password is not
sent on the wire and thus would be impossible for some evil intermediary to
figure out. The bad news is that an evil intermediary could send the hashed
password and then could be authenticated as the original sender.
To avoid this
problem, the Web Services Security Addendum has added an additional safeguard.
Instead of sending just a hash of the password, the addendum specifies that a
digest version of the password should be sent. This digest contains a hash that
is a combination of the password, a Nonce (functionally a unique string
that identifies this request), and the creation time. Therefore no two password
hashes would be the same.
PKI through X.509
Certificates
Sending X.509
Certificates as WS-Security Tokens
Besides UsernameTokens,
WS-Security also defines a BinarySecurityToken element for holding a
couple of well-known types of tokens that have their own proprietary formats.
The specification defines BinarySecurityToken types for X.509 v3
certificates and Kerberos v5 tickets. WSE supports X.509 certificates, and you
will find that in a lot of ways they are treated the same as the UsernameToken.
Accessing the
certificate on the server side is also very similar to accessing the
UsernameToken.
Transactions
support
WEB
service transaction (known as “WS-Transaction”) is a joint effort of IBM,
Microsoft and BEA systems. This specification describes coordination types that
are used with the extensible coordination framework described in the
WS-Coordination specification. It defines two coordination types: Atomic Transaction
(AT) and Business Activity (BA).
Here is the official
definitions to AT and BA:
“An atomic
transaction (AT) is used to coordinate activities having a short duration and
executed within limited trust domains. They are called atomic transactions because
they have an "all or nothing" property. The Atomic Transaction
specification defines protocols that enable existing transaction processing
systems to wrap their proprietary protocols and interoperate across different
hardware and software vendors.
A business activity
(BA) is used to coordinate activities that are long in duration and desire to
apply business logic to handle business exceptions. The long duration prohibits
locking data resources to make actions tentative and hidden from other applications.
Instead, actions are applied immediately and are permanent. The Business
Activity specification defines protocols that enable existing business process
and work flow systems to wrap their proprietary mechanisms and interoperate
across trust boundaries and different vendor implementations.”
For more information
on “WS-TRANSACTION”, look under :
State Management
One of the most
common challenges that Web developers encounter is maintaining state in the
stateless world of HTTP. There have been a number of clever means used to get
around the stateless issue, from reposting application data with each request,
to using HTTP authentication to map requests to specific users, to using HTTP
cookies to preserve the state of a series of requests.
ASP.NET Sessions
ASP.NET session
state is maintained by using one of two underlying mechanisms.
·
Cookies:
The first is by using HTTP cookies. The idea behind HTTP cookies is that when
the client sends a request, the server sends back a response with an HTTP
Set-Cookie header that has a name/value pair in it. For all subsequent requests
to the same server, the client sends the name/value pair in an HTTP Cookie
header. The server then can use the value to associate the subsequent requests
with the initial request. ASP.NET uses a cookie that holds a session ID to
maintain session state. Then that ID is used to find the corresponding instance
of the HttpSessionState class for that particular user. The HttpSessionState
class provides just a generic collection in which you can store any data that
you want.
·
Session ID: The other mechanism that ASP.NET uses for maintaining session state
works without cookies. Some browsers do not support cookies or are not
configured to keep and send cookies. ASP.NET provides a mechanism for getting
around this problem by redirecting a request to a URL that has the ASP.NET
session ID embedded in it. When a request is received, the embedded session ID
is simply stripped out of the URL and is used to find the appropriate instance
of the session object.