I think we're having some nomenclature issues. See inline for more.
Adam Taft wrote:
Peter Lacey wrote:
he wants to provide a RESTful means of having the service validate
the credentials. At least that's how I read it.
Right, I understand that. What I'm saying is that I don't think
there's a use case for "validating credentials" when all that's really
needed is for a protected resource to be requested with the
authentication process happening normally (via the traditional 401
response code).
Say, for example, you have a protected resource. This protected
resource is a resource that simply links to other resources. It
requires valid authentication and is located at:
/protected/users/
Initially, the server responds with a 401 status code, which of course
prompts the user agent to ask the user for their credentials.
Assuming correct authentication, the above resource returns a
representation with some links, like:
Right there. "Assuming correct authentication" is what I mean by
validating the credentials. When the original client sends their
credentials to the server hosting the resource, the server has to
validate them. That is it has to determine if the credentials represent
a valid username and password.
In enterprises today there's a big push towards identity management, a
component of which is providing centralized authentication and
authorization services. We don't want the resource to maintain its own
list of users with unique usernames and passwords. We want a central
directory that can be queried by a server to see if the credentials just
provided by a client are valid. Typically, this is done by the server
making an LDAP query of the central directory, but it's increasingly
common for commercial solutions to provide an "authenticate" SOAP web
service. I'm with JC in thinking it would be nice to come up with a
RESTful means of doing this, and avoiding LDAP and/or SOAP.
Once the server has authenticated the credentials it can return a 200
plus the response as follows.
/protected/users/bob/roles
/protected/users/bob/profile
/protected/users/bob/email
The fact that a user got a 200 status code indicates that he correctly
authenticated with the server. (In fact, maybe this is another good
use case for the HEAD method, if the content of the above
representation isn't useful to the client).
Anyway, so let's have a business rule that states users can only
access their own roles, profile and email page. Bob really likes to
access his email page frequently, so he bookmarks the
/protected/users/bob/email url. Bob closes his browser for the day
and goes home. Well, of course Bob uses a shared computer, and so
later Julie comes in and sees Bob's bookmarks (for some poorly secured
computer reason) and wants to check Bob's email. Of course, when
seeing the request to /protected/users/bob/email, the server responds
with a 401 and hopefully Julie doesn't know Bob's credentials as well.
Anyway, I know I'm rambling and the above is way too obvious and kind
of stupid. But, what I'm trying to portray is that generally (if
ever) a service to validate credentials is not needed, because
generally the user is really after some _real_ resource (be it a links
page like the above, a token, a list of permissions, etc). A request
to simply "validate credentials" is a vapor request with no real
benefit to the end user.
I think I understand you. You're saying that it makes no sense for a
client to call a "validate credentials" service in and of itself, if
it's only going to turn around and ask for other protected resources.
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
Where "authenticate service" is itself a resource like /users/bob that
might return useful information like what groups Bob's in and what roles
he has.
Pete
The point is, any protected resource can be used to authenticate
credentials. That's all I'm trying to say.
Adam
