views:

58

answers:

1

I am in need of an authentication system that would work in harmony with the current authentication system my client's server uses.

The current system works as follows:

  • A page requiring authentication invokes an in-house developed mod_auth Apache module in the .htaccess file.

  • The user is redirected to a generic log in page.

  • After entering valid credentials, a cookie is created, which has the IP address of the client, a public key, and other helpful info about the user, all base64 encrypted.

  • Any page requiring authentication after this point checks the public key and the requesting IP address. If the user's IP has changed, they are redirected to the login screen. If the cookie is tampered with, they are redirected.

The benefit of the above system is that a cookie can not be used on another machine (other than on the same LAN, but other measures check against man-in-the-middle attacks), as the IP address won't match.

The downside is that this method prevents the user's session from being extended server-side. In other words, a server-side script can't get information on behalf of the user since the IP address won't match.

This limitation makes sense under most circumstances, as it avoids allowing the server from "stealing" the user's cookie. However it also means that a Web Service can't be protected using the same authentication system, since requests will always come from the server's IP, never from the client (unless AJAX is used, which is a very limited usage of a web service).

What I would like is for the web service client (server-side) to pass the cookie to the web service server and have the web service server verify the authenticity of the cookie directly with the end-user's client.

My basis for this is how sites like Stackoveflow use Open ID to check log-in status at the browser level without the end-user being involved unless the check fails.

A quick wikipedia search leads me to understand that the underlying system involved is a protocol called Yadis.

So I would like to know if I am missing any pieces to this puzzle and if I'm leaving myself open to major security flaws:

  • User logs in as normal
  • Page user requests needs web-service
  • Page passes user's authentication cookie to web service
  • Web Service uses same cookie to request a generic "confirm authentication" page via user's browser. (without user seeing this).
  • "confirm authentication" page returns a "user logged in" message or the browser opens a new window with log-in page.
  • Upon receiving the "all clear" message above, web service returns any info requested by original page that user is logged in to.

Am I missing any details? Is Yadis just a name give to this idea or will I need to install something to make sure it works correctly?

A: 

The term "Yadis" can be a little murky because it's referred to different things over the years, but more than anything it refers to the discovery phase of the protocol. That is, it answers this question: given an identifier (like http://keturn.example.com/ or xri://=keturn*example or whatever), what is the authentication server to use for this user? What version of the protocol does it support?

Which, if I read your situation correctly, is not at all what you're trying to address.

What you describe, authorizing one web service to act on behalf of the server with another, is more the domain of what OAuth is meant to address. But if you're stuck with your client's currently implemented auth protocol, I'm not sure that helps you either. But it's probably worth a look, it's not dissimilar from the solution you propose.

keturn