.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

ASP.NET, ASP Single Sign-On Architecture Question

I have about ten web apps (ASP.NET & ASP Classic) in different domains.  We use ASP.NET Providers.  I want to implement Single Sign On (SSO).  I've looked for days, and don't seem to be able to find any sort of definitive best-practices or design patterns.  HELP!  How do I architect this?
Clark Bahr
Wednesday, January 02, 2008
 
 
Do you need to integrate with somebody's existing SSO system, or can you roll your own? If the latter, I can help. Been there, done that.
clcr
Wednesday, January 02, 2008
 
 
In general, SSO is implemented via cookies that share a common domain. Your remark of "in different domains" would not be very feasible unless you're using iframes and cross site scripting - unless the domains are like "app1.mydomain.com" and "app84.mydomain.com".

In the SSO applications that I've worked with, the internet-facing portions all ended up with reverse proxy servers so that the end user sees things like "app4.mydomain.com" and "app16.mydomain.com" in the browser, and those get redirected to various different boxes internally. 

There are a couple of authentication schemes that might be of some interest:
Live ID  http://dev.live.com/liveid/ 
Open ID  http://openid.net/developers/ 
Neither can be used to implement SSO directly - it would let them have one userID/password for multiple sites. Not exactly the desired goal, but perhaps close enough for now.

The following article applies to LiveID as well as OpenID:
http://www.cricketschirping.com/weblog/?p=1123

I haven't had time to look into SAML, as our existing client base use things like SiteMinder.
http://en.wikipedia.org/wiki/SAML
http://code.google.com/apis/apps/sso/saml_reference_implementation.html
http://www.csoonline.com/caveat/112706.html
Peter Send private email
Thursday, January 03, 2008
 
 
Thanks, Peter...  And, clcr, we're rolling our own.
Clark Bahr
Thursday, January 03, 2008
 
 
As Peter says, if the applications are in truly different domains you're out of luck. On the other hand, if you mean something like foo.example.com and bar.example.com, you're in luck. On each page load, have each application check for the cookie. If it's there, hand its value off to a web service that validates the token and returns the username. If the cookie isn't set or validation fails, redirect the user to a login form that authenticates them and sets a session ID cookie to be sent back to .example.com . To log the user out from all applications, invalidate the session ID server-side and clear the cookie.

Basic implementation of this sort of thing is pretty quick and easy. Pay attention to session hijacking issues and IE 7 session cookie bugs though.
clcr
Thursday, January 03, 2008
 
 
I think I've seen code that, in ASP-land, uses .net calls to do auth validation on a ticket generated by ASP.NET-land forms authentication. You might look at the asp.net FormsAuthentication class. I forget what was used for the interop, but I'd guess it would be some kind of COM thing.

Wish my memory were better.

Donnie
Donnie Hale
Thursday, January 03, 2008
 
 
I did this once.  All my domains could reach the same database so I used that. 

When they authenticated for the first time I would save a GUID, username and timestamp in the database.  On the pages that had a link to another one of my domains it would grab the GUID from the database (based on username and max(timestamp)) and hide it on the form. 

When they hit the Login.aspx on the other domain it would first check for the GUID and then look it up in the database.  If it wasn't too old the Login.aspx would set thier username and set the authenticated flag to true.  And then redirect them like normal.

This worked with the Classic ASP parts too, but I had to do more coding.
Jim Brooks Send private email
Thursday, January 03, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz