Single sign-on w/ASP?

[Paul Woods]

I'm building a few web sites that will use distinct domain names but will
reside on the same server, at the same IP address, in the same application
space, and will share a database. They will each provide different content
depending on the domain name, but will share some core functionality behind
the scenes.

What I'd like to be able to do is have one site serve as the primary site.
If a visitor comes to one of the secondary sites and wishes to perform a
function that requires them to be logged in, I'd like them to be able to log
in only once and then be able to visit any of the sites without having to
login again.

Does anyone know of a pure ASP script-based single sign-on system, or have
any tips on how to go about building one?

Thanks,

Paul

 

[Ray at]

It seems that the only way you could do this is if you track your logins in
a database. You wouldn't be able to share session variables or cookies
across the domain.

Ray at work

 

[Paul Woods]

Yes, I expect to do some tracking in the database. But then it gets tricky
because of the cross-domain issue.

Off the top of my head, I could see a process where a login request pops a
small window from the primary site. The primary site processes the login
request and then does a series of redirects to each of the secondary sites
to set a cookie that simply identifies the user and then closes the window.
Then when the user visits a secondary site, it reads the user id from the
cookie and then checks the database to see if the user was logged in.

This seems pretty kludgey though, and I'm wondering if there is a more
elegant way to do it.

 

[Aaron Bertrand - MVP]

This seems pretty kludgey though,

Yes, because as you add "related sites" this process will take longer and
longer. There is also no guarantee that the user will leave the popup
window long enough for all the sites to get registered, nor are you
guaranteed that they have scripting and/or cookies enabled, etc etc

 

[Paul Woods]

It would certainly require cookies. I'm not sure I'd be too worried about
people that didn't have them turned on. They'd be making a choice about
cookies vs ease of use, which seems acceptable. They'll just have to login
multiple times.

Perhaps it would be something where the first time the user ever logs in,
all the cookies get set as I mentioned before (again, they just set a unique
key and nothing else). Then in the future when a visitor comes to a site, a
script checks for that cookie and if it's present, checks the db to see if
they've been logged in. If so, it just transparently sets a cookie saying
they're logged in to that particular site as the page is being displayed.
If the cookie is not present (which could be for several reasons) then
they're required to login anyway and we reset the cookies as in step 1. But
the point is that the unique id cookies are persistent so once they had been
set you shouldn't have to go through the cycle of setting them all again.

There are problems with this too, but I guess I'm thinking through the
problem, hoping others will have some ideas as well. It doesn't seem like
it should be impossible, though it may turn out to be impractical.