Use OFBiz to implement Single Sign on Single Sign-on

Content
SSO Introduction
Use OFBiz to establish a simple and effective SSO Mechanism
Related Materials
Remarks

--------------------------------------------------------------------------------

SSO Introduction

--------------------------------------------------------------------------------

Single
Sign on
SSO is usually translated into single-point login, which is most commonly used in internal enterprise network applications. Users only need to perform one identity authentication when accessing internal enterprise application systems, then you can access all application systems.
You do not need to enter authentication information multiple times. SSO
It can improve the work efficiency of ordinary users and avoid the system having their own independent user accounts and passwords, thus reducing the work of system maintenance personnel. This article only describes how to use OFBiz's existing architecture to build a simple
For more comprehensive and complex SSO implementation, see the relevant documentation.

--------------------------------------------------------------------------------

Use OFBiz to establish a simple and effective SSO Mechanism

--------------------------------------------------------------------------------

First, let's take a look at the Login Mechanism of OFBiz. Open the controller. xml of any webapp and you will find this section:

<Request-map uri = "checklogin" Edit = "false">
<Description> verify a user is logged in. </description>
<Security HTTPS = "false" auth = "false"/>
<Event type = "Java" Path = "org. OFBiz. securityext. login. loginevents" INVOKE = "checklogin"/>
<Response name = "success" type = "View" value = "Main"/>
<Response name = "error" type = "View" value = "login"/>
</Request-map>

Pair
Define any request-map in controller. xml,
If its auth = "true", OFBiz will call this checklogin to check whether the user sending this request has logged on to this webapp
If not, save the current request name and post parameter in the session and distribute it to the login view to allow the user to log on. In
After a user logs in, the user reads the saved content in the session and redirects it to the previous request.

Next, let's talk about our SSO implementation. First, we must have a unified Login
The land portal and the database that stores the user account and password in a unified manner. Assume that the unified login Portal is a SSO running on a server called ssoserver.
Web application. In this SSO dB, we use the userlogin provided by OFBiz to expand another field:
Ssoid, used as a unique identifier of the user after login.

Modify checklogin to process the webapp that the user has not logged on to. Redirect the user to the SSO logon Portal:
<Response name = "error" type = "url" value ="Http: // ssoserver/SSO/control/Main? Redirect = http: // thisserver/thisapp"/>
In this way, you can achieve unified SSO entry authentication.

Now let's look at the next instance:

Step 1. A user opens the browser and sends a request to the ABC application of server.

ABC judges that this user is a new session for itself and has not logged on to it. It redirects to the SSO login portal.

Step 2. Enter the user name and password at the SSO login portal.

SSO webapp performs user name and password verification to generate a unique ssoid, save the corresponding userlogin, and construct a link using the Redirect parameter obtained earlier:"Http: // aserver/ABC/control/autologin? Ssoid = generatedssoid.

Step 3. Automatically log on to the ABC application of aserver

Autologin
Is a request-map implemented by us. Its function is to use ssoid to uniformly store userlogin SSO
DB obtains the corresponding userlogin and performs an automatic login. After login, it is still the same processing mechanism as the original OFBiz. It will read the previously saved content in the session
To the request sent in step 1.
At this time, it seems that there is no difference with the original login method, but if the user continues to operate:
Step 4. send a request to the EFG application of B server.

EFG judges that this user is a new session for itself and has never logged on. It redirects to the SSO login portal.

Step 5. SSO web app judgment

The SSO web app will know that this user has already logged on to SSO. Do not ask the user to log on again. Use the ssoid and redirect parameters to construct a link like this:"Http: // bserver/EFG/control/autologin? Ssoid = generatedssoid.

Step 6. Automatically log on to the EFG application of bserver
OK, 4 ~ 6 is SSO, which is completely seamless for users.

To sum up the work of implementing SSO on OFBiz and the points worth attention:
1. Write an SSO web app, run on a unified SSO server, and use a unified SSO database.
2. For any application that needs to integrate SSO, modify the Web apps checklogin method and add an autologin method.
3. in actual implementation, the SSO login web app we write the user login information in a cookie, so that even if the user opens a new browser, the SSO web app can obtain the user's login information from the cookie.
4. in actual implementation, considering that ssoid may be constructed to log on multiple times, the length of ssoid can be increased (255 characters ), the chance of brute-force cracking is almost zero.
5.
This method is not limited to OFBiz, but can be applied to other Java Web apps, ASP, PHP, and so on. As long as the login of other web applications is unified to SSO Web
The app can integrate SSO through ssoid verification. For example, ASP: we only need to redirect to http:
// Cserver/hij/autologin. asp? Ssoid = xxx. (In practical applications, we use this method to integrate old notes, ASP,
PHP and other systems .)

--------------------------------------------------------------------------------

Related Materials

--------------------------------------------------------------------------------

This article introduces a simple and effective SSO method. The design idea is from the login of. NET Passport of MSN (Http://www.msn.com/By tracking its login process, you will find that it is also implemented using similar redirection ). Below are some other related SSO documents

SSO in WebSphere Environment
Introduction to SSO on the server side
Implement SSO using Web Service
An opensource SSO lib of Yale University
Introduction to SSO in opengroup

--------------------------------------------------------------------------------

Remarks

--------------------------------------------------------------------------------

I would like to add some explanations for this article:

Q1. how many systems do a user have different user names? How does SSO handle this situation?

Our simple implementation cannot solve this problem.

Q2. do the logins of the original system need to be maintained in the SSO dB, and the userlogin must be maintained in the dB of the application system?

Various
There are no tables such as userlogin in the application system dB, but this will cause some problems. If there is a view created in the application with userlogin
Entity, which needs to be modified, but there are few such view entity, usually to get the partyid,
However, because the data of the party is still in the database of each application system, it can be solved by modifying it to the party. In addition, the entity definition for setting up a foreign key with userlogin also requires
Modify because most databases do not support cross-database Foreign keys.

Q3. if it is maintained in SSO dB. Where are the permissions of userlogin maintained?

The security group maintenance for userlogin is still performed in their respective application systems, because the permission settings of a user in each system must be changed and cannot be performed in SSO.

 

Reprinted from: http://www.4ucode.com/Study/Topic/1782506