Adam Taft wrote:
Peter Lacey wrote:
In that I agree. But in my scenario the client of the "authenticate
service" is the resource being accessed, not the client requesting
the resource. Visually:
CLIENT ------ uname/pwd -------> RESOURCE ------ uname/pwd ------->
AUTHENTICATE SERVICE
Right, gotcha. The diagram helps. :)
So, in identity management, you're usually not just wanting to
"validate credentials," but generally want to also return other data,
like maybe the user's full name, email,
permissions/authorizations/roles, valid login times, token & token
expiration, last login time, etc.
Exactly!
The request to the AUTHENTICATE SERVICE would generally return at
least some resource that is applicable to your RESOURCE server. But,
if there is absolutely no resource representation that is useful to
the RESOURCE server from the AUTHENTICATE SERVICE, then I think the
suggestion to use HEAD would be appropriate.
If you're only interested in the response code, sure. But it's more
likely that you would want some representation back.
I guess the biggest thing I don't like is including any sort of
password, encrypted or not doesn't matter, in the URL. This is just
asking to be recorded somewhere too easily, and then subject to play
back attacks.
Agreed. I've backed off that idea.
I still think that an "authentication service" like you're describing
should use a url scheme like /protected/{username} and use the
built-in HTTP authentication mechanisms. You get the benefits of HTTP
caching and other good things of using this well defined scheme.
Also agreed. That was my second proposal:
http://permalink.gmane.org/gmane.comp.java.restlet/3170
Pete
