you need to decide how login info is passed from the login server to the
application servers. lets pick a guid.
1) the application logon page redirects the login server to login in.
2) the login server validates the login with AD and assigns a login guid
3) the login server store the login guid, and associated roles in its
session cache
4) the login server redirects back to the application site's logon page
passing the guid in the url or cookie (using a cookie will require the
login server and application servers have a common dns root)
5) the application site retrieves the login guid from the url or cookie
6) the application site calls the login server passing the guid to get the
login creditals (the application server should pass some verification data
to prove who it is - maybe a certificate - or a special login).
7) the application site builds a login ticket with the login creditals.
8) the application site redirects back to the originally requested page.
-- bruce (sqlwork.com)
"Beginner" <bz****@hotmail.com> wrote in message
news:ON**************@TK2MSFTNGP12.phx.gbl...
I know this is an old question, but searching all over the internet plus
several MS security conferences, still haven't got a straight anwser.
Basically, the login.aspx is on one dedicated server in the domain using
AD. ASP.NET applications run on other servers (not neccessary in domain) and
trying to use authentication server. How could this be done?
- Most response says you need to set MachineKey the same, but that alone
doesn't seem enough
- There's one article says the login.aspx needs to set a third-party
cookie for the requester in order for them to retrieve (sounds reasonable, any
examples?) Any workaround if not so sure about browser privacy settings?
Anyway, the goal is have a central .NET based form authentication for all
our intra-net web applications.
Thanks.
