views:

62

answers:

2

I am looking into creating a global ID system for all of our online products including our own company web site (we don't have any products that are public quite yet, but we are fairly close). If we were completely a .Net shop this wouldn't be much of an issue, but we have at least ASP.Net MVC and Ruby on Rails, and who knows what else we'll have in the future.

How would you implement this type of system in a diverse environment? Would you use an internal web service for authentication?

+1  A: 

Yes, something covered by standards like a SOAP webservice would be the most obvious way.

Easy to write in C#/.net, and provided you are aware of cross compatibility issues it should be consumable by any other language/platform.

Make sure you Google around for web service interoperability information first as there are some gotchas. There is a blog post here on some common things to check for.

Simon P Stevens
+1  A: 

I've done this recently and it is fairly simple on the high level:

  • Create a web service that authorizes credentials (user / pass) and then issues an authentication token (such as guid). This token will expire at a set time, or when the user logs out. The token can be stored in a cookie for web apps, or in client memory for client / server apps.
  • As the user moves from system to system, the individual systems should check with the authentication service to see if the token is still active. If not (such as in the case of a timeout or fake token), it should redirect the user to the global login.
  • Nice to have feature, but not essential: As the user is active in a system, it should occasionally call to the authentication service and refresh / extend the lifetime of the token.

Obviously, running your own OpenID or OpenAuth server should be explored as an option before you go writing a custom solution.

Daniel Auger
How do you handle keeping someone logged in from multiple services that are on separate domains? Is that even possible?
Max Schmeling
The best you can do is issue a cookie at a shared domain level. Example: if you issue the cookie for the "mycompany" domain then you can share the cookie across app1.mycompany.com and app2.mycompany.com. If your services don't share an upper level domain, then something like an OpenID server may be a better way to go.
Daniel Auger