Sort it out:
1 For pure web SSO, if there is an independent SSO Login server, all the verification will jump to the interface of this server, the login status will be retained on the SSO Server
2. If you want to authenticate the desktop and web, you must have an independent SSO,
For self-implemented solutions, for example, if a desktop program is used to implement SSO, there must be an SSO server. The desktop program verifies the identity through httpclient, and then can pass
A. modify local cookies to allow IE to pass authentication tokens
B. directly use the authentication token as the URL string root after a link of the desktop program
The token statement is vague. There are two methods:
1. All URLs have a rewrite token.
2. As long as you retain the browser's cookies for the SSO web server, when you jump to the application, the web app will first redirect to the ssoserver. After verifying the cookies, the web app will jump back. For users, they will not feel like they have been to ssoserver, haha,
Many websites, such as Google, seem to be using this method.
In essence, JAAS only solves the problem of configurable login. For example, if Tomcat uses JAAS, it can only solve the problem of logging on to N applications on Tomcat at the same time, and it is limited to Java. The above method is required for SSO implementation. Kerberos and system 1
These modules are closely integrated, making expansion inconvenient.
3 if windows is the only logon portal, that is, there is no second SSO Login server.
The core of SSO is that IE can send domain information to the server after the merge domain:
Configure IE browser
① Internet Options --> Security --> Local intranet --> site --> advanced
Add WLS
② Internet Options --> advanced --> Security
OK. Windows identity authentication is selected.
After WebLogic of the Service segment receives this token, it must go to the ad for verification.
Integrated with Windows authentication (formerly known as NTLM authentication and Windows NT question/Response Authentication), NTLM or kerbetas authentication can be used. NTLM is a proprietary Microsoft technology, several updates have been made since its publication,
Although this mechanism is stable and reliable, it has a fatal drawback that it cannot be delegated, which means that user creden。 cannot flow to remote services (such as SQL Server ). However, Kerberos does not have this problem. It maintains a stable and secure verification server.
You can also easily use delegation in a Windows environment. We will discuss this mechanism.
Microsoft Active Directory is required for Kerberos in most cases because Active Directory acts as a Kerberos token to authorize the Service (TGs/TGT ).
If Kerberos is used, it is easy. Both windows and WebLogic support Kerberos, and the authentication data is on the Active Directory.
Reference http://edocs.bea.com.cn/wls/docs92/secmanage/sso.html
Trackback: http://tb.blog.csdn.net/TrackBack.aspx? Postid = 1788453