- From: David Morris <dwm@xpasc.com>
- Date: Fri, 27 Feb 2004 15:17:36 -0800 (PST)
- To: Jim Flath <jim_flath@yahoo.com>
- Cc: <ietf-http-wg@w3.org>
Jim, Basic authentication is pretty obnoxious. Running under HTTPS removes the fundamental security concern, exposure of open text credentials, but it is a stateless protocol. Each client request must carry the credentials which must be validated by the server. If my memory hasn't failed, a client is permitted to anticipate that a new URL is part of a particular realm and offer the credentials. Certainly, once the specific URL has had user entered credentials, the clients send the same credentials on the next request. I have observed in the past that some clients may send the same credentials for other URLs which reference the same 'directory' or even child directories. The server must sent the 401 when it doesn't believe the client is correctly authenticated, either because there were no credentials or the credentials are wrong. It is a slippery slope to expect a user to be prompted if 401 is sent in response to correct credentials. There is no protocol mechanism for requesting a client purge credentials. The only influence the server has over the user authentication dialog is the 'realm name' so usability is poor at best. I haven't seen a moderate to high volume production site in years which uses basic or other client supported authentication. That of course isn't an exhaustive survey. I find basic authentication most useful in situations where the web security requirements are equivalent to physical security satisified by an unguarded locked fence. Perhaps a beta release of a new version or a a design review where you want to avoid access by casual browsers and robots. Application controlled authentication provides the most robust user experience and the most server flexibility. In simple terms, include a login page which authenticates the user and then uses a cookie or URL decoration to track the user session. Enforcement can be achieved with application page logic, app server support, etc. Beyond the scope of this list to discuss the alternatives. Dave Morris On Fri, 27 Feb 2004, Jim Flath wrote: > > I am building a system that is constructed using servlets and JSPs, I also utilize Session’s and client cookies. > > > > I am curious if I am truly implementing Basic Authentication or a mutated version of that. Here is the flow: > > > > First request: > > Client makes initial request to a secure resource. > > Server finds no session data to indicate previous authentication. > > Server checks header values for credentials, no credentials found, replies with a 401 status code. > > Client receives 401 and prompts for credentials, receives user input and sends the authentication header data. > > Server interrogates the header data and authenticates the user to the realm > > Server saves user data and flags in the session to indicate that they have successfully authenticated to the realm. > > Server serves up the resource. > > > > Subsequent request with a valid session: > > Client request to same or different secure resource within the same realm. > > Session is still valid and server finds authentication flags in the session, does NOT resend 401 status code. > > Server serves up the resource. > > > > Subsequent request with invalid session: > > Subsequent request to same or different secure resource within the same realm. > > Session has been invalidated, no session data found. > > Server checks header values for credentials, no credentials found, replies with a 401 status code. > > Client receives 401 and sends cached credentials in the authentication header. > > Server interrogates the header data and authenticates the user to the realm > > Server saves user data and flags in the session to indicate that they have successfully authenticated to the realm. > > Server serves up the resource. > > > > Does the server need to reply with a 401 for each and every request to a secure resource within the same realm to say I am using Basic Authentication? That type of model would seem to be inefficient. I understand that HTTP is a stateless transaction, but with the addition of sessions and cookies the entire transaction becomes stateful to a point. > > > > FYI, the entire transaction is accomplished using HTTPS/SSL. > > > > > > --------------------------------- > Do you Yahoo!? > Get better spam protection with Yahoo! Mail
Received on Friday, 27 February 2004 18:23:12 UTC