Large Internet sites have a lot of independent network applications, and each application requires a user to see the content after login. Obviously, you don't want to engage in your own login scheme in each app, set your own landing page. Besides, if the user needs to log in once, it is very troublesome. We need a unified landing scheme that can access other applications at once.
I have seen some suggestions in the forum, generally use ASP.NET based on Form-based authentication methods, one of which is to turn all applications into subdirectory, not separate virtual directories, and then set up in a virtual In the directory, then set a single authentication in a virtual directory. But this program is probably only applicable to network applications to focus on a single server, and forced to virtualization also reduces relative independence of them.
Of course, Microsoft has provided a good solution, Passport certification service. ASP.NET also supports this service, see the class name starting with Passport under System.Web.Security namespace. If you want to use the Passport authentication service in your app, you need to download .Net Passport SDK, you can refer to
.NET Passport Single Sign-in
Or this article on the DEVX website
SET UP Passport Authentication in ASP.NET
See how setting it.
But in many cases, this program may not be very appropriate, but we can imitate the working mechanism of Passport certification services to customize a solution. On the MSDN, it seems that the detailed Passport protocol content is not found, and this page found is not detailed. You can refer to the following article to learn about the Passport authentication process:
ENABLE SINGLE SIGN-ON ASP.NET with Passport
But the approximate process is like this:
One. Users visited a web page on your website. Two case A. If your webpage finds that the user has not been authenticated, the authentication login (SIGN) button is displayed. The user presses the login button 2. Your web page re-directions the user requests the authentication server and provides ID 3 of your website. Two cases a. If the authentication server finds that the user has not been authenticated, the authentication server displays the username / password login form, the user enters the name / password. After the authentication server authentication, generate a authentication cookie in the user browser, and re-direction the user requests back to the original Your webpage and provide Ticket and user profile information encrypted with the public key of your website you first in the URL, which refers to the above article B. If the authentication server finds that the user has been authenticated (perhaps in other applications / websites), the authentication server updates the authentication cookie, and re-directions back to your webpage, and provide you in the URL. Ticket and user profile information of the website public key encryption
Your webpage checks the URL, use the private key of your website, get user information, generate an authentication cookie, then display the exit authentication (SIGN OUT button
B. If your webpage finds that the user has been authenticated, the Sign Out button is displayed.
three. If the user clicks to exit the authentication button, a request to the authentication server's exit authentication webpage will be triggered. If the authentication server's exit page is generated for each current user has logged in to the application / website for each current user. Attribute SRC points to the exit authentication page of each application / website and expires the authentication of the authentication server. The exit authentication page of each application / website expires its own authentication cookie.
As a result, if the user clicks to exit the authentication button, he will exit all applications / websites currently logged in. Of course, your customization plan may not be so complex or strong, you can consider not using PKI.
Transfer from: http://blog.joycode.com/saucer/archive/2004/02/25/13789.aspx
