- Mar 30, 2001--- In soaplite@y..., r_amselli@y... wrote:
> I am fairly new to SOAP Lite but I have read a lot about SOAP.
> In everything I have read, the authors were saying that SOAP was
> HTTP and so that the authentication systems were the same._____________________________
> My question is how the authentication system works with SOAP Lite:
> what I would like to do is give access to a SOAP server on ly to
> certain clients.
> Any Idea or code examples please?
> Thank you
First, a primer on authentication...
The basic authentication (AUTH_TYPE = Basic) provided by the HTTP
protocol is where a small dialog box with prompts for "User Name"
and "Password" pops up over the browser window. In Netscape, the
dialog box title is "Username and Password Required"; in Internet
Explorer, it might be "Enter Network Password".
If the user hits Cancel, or enters an invalid username or password,
they get an HTTP Error 401 "Authorization Required". Similarly,
unless the proper authentication parameters are passed in the HTTP
request, a SOAP::Lite client will get an error message "SOAP call
failed: 401 Authorization Required". If authentication fails, the
user does not get access to the file that was requested, whether that
file is a static HTML file, a CGI program, or a SOAP server. For the
static files this works pretty well.
However, many web sites nowadays have content that is dynamically
generated by server-side programs. To provide for additional
features such as various login options ("auto-login", "save
password", etc.), access to content without signing on (usually along
with a "Sign On" option), the ability to "Sign Off" or change user
names, and more graceful failures than "401 Authorization Required",
most web sites implement their own authentication mechanisms handled
by server-side programs. Typically, they get a user name, password
and other parameters from a login form, determines whether the user
should be allowed access, and return a page that somewhere indicates
whether the user is successfully logged in.
One important thing to note is that each web request is processed on
the server as a totally independent transaction: connect - input -
process - output - disconnect. For every transaction, you must
determine whether or not the user has an existing session. If you
don't authenticate every transaction, bad things can happen. For
example, if you are running a web-based e-mail service, without re-
authentication a user could change the user name in the URL and gain
access to someone else's mailbox. Remember URLs can come from
various places: The "Address" or "Location" bar, "Bookmarks"
or "Favorites", and links and forms from other web pages or in e-
mails. You shouldn't count on these URLs coming only from trusted
sites -- there have been some cases where forms have been set up on
the web that would generate the proper URL to allow you to access
someone's web-based e-mail simply by entering their user name in a
If you use a login page for authentication, you probably don't want
to redisplay the login page for every page the user sees, so a
different mechanism is needed for re-authentication. One popular
method is for the login to return a session key that is somehow
passed back to the server on the next transaction. Typical methods
of saving and returning the session key include cookies, URL query
parameters, and hidden form fields. This is better than some other
approaches, such as storing the user name and password on the client,
where they could easily be viewed by anyone with physical access to
And how it applies to SOAP...
As you noted, the authentication mechanisms for SOAP clients are the
same as for other HTTP clients, especially since most of those
mechanisms are implemented on top of the HTTP protocol. In other
words, you have to extend your existing web authentication mechanisms
to handle SOAP clients.
Our company's existing authentication mechanisms use session keys.
We have been working on extending them to work with SOAP clients,
which has also necessitated making them much more robust, because
some of the information from a SOAP client will be coming in
indirectly rather than directly from the CGI interface, and therefore
will be less trusted.
What's nice is that once our SOAP authentication is working, it could
be used from anywhere on the Internet: web pages, UNIX Telnet
clients, Windows clients, etc. -- and could even be used by other web
sites to provide authentication for their clients. Information could
be shared (carefully) among web sites -- for example, a user could
specify an option indicating whether they want their e-mail address
provided automatically to a web site requesting it, or only to web
sites they authorized for that information; any web site could
determine whether or not the user had validated their e-mail address
by responding to a confirmation message, regardless of which web site
originated the message, eliminating the need for the user to re-
validate their e-mail address for every web site they visit.
Here's how it would work: The SOAP client (which could be a native
program or script, or a web site CGI program) would prompt the user
for a user name and password, plus other optional parameters, if
desired. The client would send this information to the server via a
SOAP call, and get back a status and, for a valid login, a session
key. For subsequent calls, the client would send the session key,
and the server would return the session status (valid, expired, etc.)
plus various other session information.
We are hoping to begin beta testing of the SOAP authentication in the
near future. If you would be interested in participating in such a
beta test, please send me an e-mail at betatest@... and
I will add you to the list of potential beta-testers.
- << Previous post in topic Next post in topic >>