Loading ...
Sorry, an error occurred while loading the content.

156Re: Authentication

Expand Messages
  • Robert Simpson
    Mar 30, 2001
    • 0 Attachment
      --- In soaplite@y..., r_amselli@y... wrote:
      > Hi,
      >
      > 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
      over
      > 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
      >
      > Raf

      _____________________________
      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
      form.

      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
      the machine.

      _____________________________
      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.
    • Show all 7 messages in this topic