| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| Dear All
|
| We have an application where users login, their name/password details are
| stored in a table, and now we want to add a third party bulletin board
that
| lives in its own virtual directory. Both applications are running on the
| same IIS.
|
| How do we authenticate users so that they don't have to sign in again
| without passing their name and password in the querystring or request
| header? The login details are the same for both applications.
|
| --
|
| Joe
|
|
|

"Steven Cheng[MSFT]" <stch***@online.microsoft.com> wrote in message
news:4xwUJr2BGHA.3992@TK2MSFTNGXA02.phx.gbl...
> Hi Joe,
>
> Welcome to ASPNET newsgroup.
> As for the implementing a single signing on system in our mutiple asp.net
> web application question ,here are some of my understanding and
> suggestion:
>
> 1. For single signing on system, we need a central authentication
> authority
> which store all the user accounts..... Then, all the other application
> which need sign-siging-on need to share that authority........
>
> 2. For ASP.NET appliation it is web based, then the problem should be how
> to stored info of the authenticated user between mutiple
> application(utilizing the same SSO authority...).  currently the Microsoft
> Passport is such a central authority, if we use passport, we can
> assosicate
> passport account with our certain web applications' own security account
> system....
>
> If we don't use passport, we need to implement such as central authority,
> since web application is browser based, it's hard to store some client
> user
> specific states accross mutiple application. So far I think the cookie
> should be the only possible means. For example, we can implement a SSO web
> application system as below:
>
> have a central security authority that can authenticate based on
> username/password ( a certain login page...), after user login, store some
> token/tikcet to identity user through persistent cookie on user's
> clientside...    This central authority application also need to provide a
> web page which can be requested by other application to check this client
> tiket and redirect back to other page's url....(through querystirng....)
>
> Then, in other web application (which need to share authentication info
> from that central auhority), they need to also provide an checking page,
> this page will redirect to the certain page (mentioned above ) in central
> authority app, then, get back the authenticate info (through url
> querystring...), if authenticated, we can let user continue, else redirect
> it to that central authority applciation's login page....
>
>
> Also, there're some 3rd party SSO solution over internet, you can also
> have
> a search to see whether any of them helps.
>
> Thanks,
>
> Steven Cheng
> Microsoft Online Support
>

| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| "Steven Cheng[MSFT]" <stch***@online.microsoft.com> wrote in message
| news:4xwUJr2BGHA.3992@TK2MSFTNGXA02.phx.gbl...
| > Hi Joe,
| >
| > Welcome to ASPNET newsgroup.
| > As for the implementing a single signing on system in our mutiple
asp.net
| > web application question ,here are some of my understanding and
| > suggestion:
| >
| > 1. For single signing on system, we need a central authentication
| > authority
| > which store all the user accounts..... Then, all the other application
| > which need sign-siging-on need to share that authority........
| >
| > 2. For ASP.NET appliation it is web based, then the problem should be
how
| > to stored info of the authenticated user between mutiple
| > application(utilizing the same SSO authority...).  currently the
Microsoft
| > Passport is such a central authority, if we use passport, we can
| > assosicate
| > passport account with our certain web applications' own security account
| > system....
| >
| > If we don't use passport, we need to implement such as central
authority,
| > since web application is browser based, it's hard to store some client
| > user
| > specific states accross mutiple application. So far I think the cookie
| > should be the only possible means. For example, we can implement a SSO
web
| > application system as below:
| >
| > have a central security authority that can authenticate based on
| > username/password ( a certain login page...), after user login, store
some
| > token/tikcet to identity user through persistent cookie on user's
| > clientside...    This central authority application also need to
provide a
| > web page which can be requested by other application to check this
client
| > tiket and redirect back to other page's url....(through querystirng....)
| >
| > Then, in other web application (which need to share authentication info
| > from that central auhority), they need to also provide an checking page,
| > this page will redirect to the certain page (mentioned above ) in
central
| > authority app, then, get back the authenticate info (through url
| > querystring...), if authenticated, we can let user continue, else
redirect
| > it to that central authority applciation's login page....
| >
| >
| > Also, there're some 3rd party SSO solution over internet, you can also
| > have
| > a search to see whether any of them helps.
| >
| > Thanks,
| >
| > Steven Cheng
| > Microsoft Online Support
| >
|
| Thanks for that.
| It basically confirms what we thought but I hoped we might be missing
| something obvious.
| Joe
|
|
|