How are you modeling authentication operation?

[schatekar]

I am currently working on enhancing user service which would be consumed by several other services. Other than offering basic CRUD functionality around users this service is also supposed to act as a SAML enabled id provider and so it needs to be able to authenticate users somehow. The current implementation looks like below

PUT /authenticate

{
Userame: {username},
Passowrd: {password}
}

This returns a true or false depending on success or failure of authentication. I am thinking of changing this to be more RESTful. I am thinking on these lines.

Authentication is a process so there is real resource involved here. Should I define a new virtual resource? What should this resource be? Something that gets created when authentication succeeds? A LoggedInSession? A SecurityContext? SecurityContext sounds better. So let's design the API as below

POST /securitycontext

{
Userame: {username},
Passowrd: {password}
}

Not sure if I am thinking in the right direction.

[geemus]

It depends a lot on how your authentication works. ie, in many cases it makes sense to just pass auth in the Authorization header (using basic or token auth perhaps). SAML is a special case though, and one (I must warn you) I am not very familiar with. I read the wikipedia page a bit to give myself a rough idea, and given that I would say something like POST /security-contexts would probably make a lot of sense. I'd just note two small differences from what you suggested: 1) plural spelling of context and 2) dasherize the space between the two words. Both of those are just to follow existing conventions. Although singular spelling might make since if this is a singleton (as I suspect it might be), ie if each user would only ever have a single valid context. That said, I think just always using plurals can be nice for the sake of consistency also. Hope that helps, but happy to discuss further as needed. Thanks!