I think you might be missing the point of JC's original request. It's
not that he wants to provide some new means of authenticating to a
service, he wants to provide a RESTful means of having the service
validate the credentials. At least that's how I read it.
In other words, a client can authenticate normally (say Basic over SSL)
to a service. The service then has to validate that the credentials
(username, password) are valid. Today, that's typically done by
querying a local identity repository (the database or a special purpose
directory) or a remote, central repository (typically a directory).
What I think JC wants is the ability to call out to a remote, central
user repository to perform authentication (and possibly to gather enough
user attributes to make authorization decisions) in a RESTful manner
rather than having to use LDAP.
Pete
Adam Taft wrote:
JC wrote:
I am trying to develop a Restful login system.
I have never found a form or url based authentication system that felt
anywhere near as good (or even as RESTful) as using Basic
Authentication over SSL.
First of all, I believe people need to get over this concept of
"logging in." For a RESTful request, there really is no such thing;
logging in implies server state and sessions, which of course is not
RESTful.
When you request a protected resource, the server should simply expect
proper authentication headers to be included in the request. If
they're not there (or possibly invalid), it returns a 401 status.
It's up to the user agent to provide those credentials and build the
appropriate header entry. The HTTP header is the appropriate place to
do so because otherwise you have to pass it on the URL, which of
course is yucky.
Anyway, I think the first step is getting over the "logging in" thing.
It's really contrary to REST.
Hope this helps,
Adam
