On Thu, Sep 17, 2009 at 18:15, Mike Moulton <[email protected]> wrote: > My applications undergo auditing to meet strict security protocols, therefor > I generally stay away from BASIC auth due to the in-the-clear nature of the > Authorization header unless the entire session is planned to be delivered > over SSL. With the exception of Eric's implementation where a crypted > version is stored on the server and referenced by a session id, how are > others dealing with these inherent security risk in a production > environment?
On Thu, Sep 17, 2009 at 17:51, Vidar Ramdal <[email protected]> wrote: > I realize that authentication must be hard in any truly REST-based system. Using HTTP basic auth (no cookies) + SSL is probably the way to go for REST-based systems. Other than that, you could try all kinds of things to either make user sessions (at least the secret keys) be distributed around the cluster fast (good potential for failure) or make the load balancing put users always on the same server (or set of servers that are easily synchronized), to keep scalability. And only do that for users that need to be logged in so that the anonymous GET requests are unaffected by that and stay fully scalable. Also, Kerberos could be an answer, but I don't know if it is scalable or if it is possible to use it across all browsers. Regards, Alex -- Alexander Klimetschek [email protected]
