By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,408 Members | 1,796 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,408 IT Pros & Developers. It's quick & easy.

Single Login Problem

P: n/a
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
Dec 22 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
| From: "Joe Fawcett" <jo********@newsgroup.nospam>
| Subject: Single Login Problem
| Date: Thu, 22 Dec 2005 12:07:51 -0000
| Lines: 16
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| X-RFC2646: Format=Flowed; Original
| Message-ID: <e8**************@tk2msftngp13.phx.gbl>
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: 212.58.51.2
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msft ngp13.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:366530
| 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
|
|
|

Dec 23 '05 #2

P: n/a
"Steven Cheng[MSFT]" <st*****@online.microsoft.com> wrote in message
news:4x**************@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
Dec 23 '05 #3

P: n/a
You're welcome Joe,

Thanks & Merry Christmas,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
| Reply-To: "Joe Fawcett" <jo********@hotmail.com>
| From: "Joe Fawcett" <jo********@newsgroup.nospam>
| References: <e8**************@tk2msftngp13.phx.gbl>
<4x**************@TK2MSFTNGXA02.phx.gbl>
| Subject: Re: Single Login Problem
| Date: Fri, 23 Dec 2005 09:29:01 -0000
| Lines: 60
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180
| X-RFC2646: Format=Flowed; Original
| Message-ID: <uf**************@TK2MSFTNGP10.phx.gbl>
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: 82-32-192-127.cable.ubr05.newt.blueyonder.co.uk
82.32.192.127
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFT NGP10.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:366741
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| "Steven Cheng[MSFT]" <st*****@online.microsoft.com> wrote in message
| news:4x**************@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
|
|
|

Dec 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.