Single Sign On

From BSG Knowledge Base

Jump to: navigation, search
Single Sign On Process in BSG LeatherLink Applications

Objective:

Single Sign On (SSO) is an user authentication process that permits a user to enter in a single login and logout process in order to access multiple applications. It will authenticate the user for all the applications, when they have a rights to access this application. This is convenient for the users and also for time saving.

Existing System:

In the existing system, we have separate login pages for each and every applications. If we wants to see any 1 or 2 applications, even though we have same username and password for both applications, we must login in the corresponding application login pages. Then only, we have enter into corresponding application pages and access it.

Disadvantages:

  1. It is not convenient for users
  2. Time consuming
  3. Difficult to remember passwords for multiple applications

Proposed System – 1:

First, we have started Single Sign On process using the techniques of curl, md5 encryption, json, etc. It have separate database for single sign on process and it contains 2 main tables.

  1. single_signon
  2. single_signon_apps

Working Process :

  1. When user enters username, and password, it will goto common index page ( or any application page ). From that, we can access other applications via navigation links for other applications.
  2. User name, password and login time will be stored in above 2 database tables of single_signon and single_signon_apps.
  3. These 2 database tables have relationship with each other.
  4. While login, the system will generate token id for a corresponding user and it will be stored in session.
  5. We can set the expire time for this session, when it have to be expired.
  6. Within the session time, we have full access rights to access all applications at the same time.
  7. Token id takes first 10 characters based on md5 encryption of last login time and password.
  8. For that token md5 encryption, we also have to encrypt all application password in md5 encryption formats.
  9. Once we have encoded, there is no possible to decode and no way to retrieve the original password.
  10. We have faced the problem in handling this token in session.

Sample token generation for each applications:

  1. {"scm.singlesignon":{"globalId":"leatherlink@TMS","token":"06b503f5"}}
  2. {"scm.singlesignon":{"globalId":"leatherlink@FMS","token":"f7a6f823"}}
  3. {"scm.singlesignon":{"globalId":"leatherlink@CMS","token":"04cdea02"}}
  4. {"scm.singlesignon":{"globalId":"leatherlink@EMS","token":"04b253h3"}}

Proposed System – 2:

Next we moved to create one class for singlesignon which should get the username password and application code, then generate gid and stored this gid in cookie at root path with the expire time of 6 hours. From that gid, we can access all applications at same time.

Working Process:

  1. User will give the username and password in single sign on login page.
  2. It will goto common loginscript file in website and it will authenticate the user using the authenticate() function, and get the gid (user_id) for this user, and store it in cookie.
  3. Then redirect the page to single sign on login page itself, and show the welcome username message.
  4. Now, we can access all applications and tools, only if we have the access rights.
  5. Using _100111 schema for authentication, and add column “gid” in all applications master_user tables.
  6. Using this gid, we can authenticate that whether the user is valid user or not.
  7. Gid is stored in cookie at root path with the expire time of 6 hours.
  8. Also get this cookie value of gid in all application and create the session name as application name for each applications for differentiate the process involved in each applications.
  9. That gid present in each application schema is referenced the user_id in _100111.sys_master_user table and _100111.sys_master_user_company_relation table.
  10. We have write 3 functions for get user_id, schema, and username for authentication under the class SingleSignOn, and named this file as global_authentication.inc and store it in all application's includes directory.

Functionalities of authentication functions in global_authentication.inc file:

  1. function authenticate() :
  • When the user enter the username and password in login page, that will be posted and this function will get this values, and retrieve the user_id from _100111.sys_master_user table using the postgresql query.
  • This user_id is called as “gid” in that single sign on process.
  • If the user_id is not available for that posted username and password, it will give the error message of “you are not registered user”.
  1. function getSchema() :
  • The application code is hard coded in each applications, like tms, fms, ems, sd, and forum.
  • Using this application code, this function will retrieve the company_id for corresponding application from _100111.sys_master_user_company_relation table where the user_id is must same as _100111.sys_master_user table.
  • This company_id is called as “schema” for an application.
  1. function getUserName() :
  • Using the user_id getting from the authenticate() function, this function will retrieve the login_name for corresponding application from _100111.sys_master_user table.
  • This login_name is called as “user name” for an application.

Functionalities of loginscript.php file:

The loginscript is changed as to access applications in 3 cases:

  1. Application login will work, when gid is get from _100111.sys_master_user table and going to authenticate with corresponding application schema.
  2. Else it is going to perform authentication in _100111 schema, and normal authentication process in that corresponding application schema.
  3. Otherwise it is going to perform authentication corresponding application schema and without using _100111 schema.

Condition no – 1:

  • User will give the username and password in single sign on login page, then it will goto verify that username and password, whether it is present in _100111.sys_master_user table or not.
  • If this username & password available in _100111.sys_master_user table, then get gid (user_id) for that user and stored this gid in cookies. Show welcome message for the user.
  • Then user can access all applications present in that single sign on page only if they have rights to access it.
  • If the user select one application, then it will goto corresponding application loginscript and get gid (user_id) from cookies, and get the user_id from corresponding application master_user table using this gid.
  • If it is available, then get the user_id, and goto further conditions using corresponding application schema.
  • If gid is not in cookie. it will go with next option.

Condition no -2:

  • Get the loginname and password from application login page, then it will goto verify that username and password, in corresponding application master_user table.
  • If it is available, then get the user_id and schema is hard coded, and goto further conditions using corresponding application schema.
  • If user_id is not in table, it will go with next option.

Condition no -3:

  • User will give the username and password in single sign on login page, then it will goto verify that username and password, whether it is present in _100111.sys_master_user table or not.
  • If it is available, then get the user_id and member_id as schema, and goto further conditions using corresponding application schema.
  • If user_id is not in table, it will display error message, and goto index.php page.

Functionalities of global_session.inc file:

  • Gid is stored in cookie at root path with the expire time of 6 hours.
  • Also get this cookie value of gid in all application.
  • Create the session name as application name for each applications for differentiate the process involved in each applications.

Functionalities of logout.php file:

  • To destroy the cookies and sessions handled in all applications.
  • If we logout one application, it will automatically logout all applications, that is presently accessed by users.

Design Structure of Single Sign On Process:

In Single Sign On (SSO) deployment, we will manage Web access and single sign-on (SSO) with a string named gid (token), which travels through the Web browser, the related Web applications, and the Single Sign On instance. Gid (token) is a handle that contains the information of the login session in the Single Sign On instance. When a user attempts to log in through the browser, this process takes place:

  1. SSO sends gid (token) as a cookie to the browser.
  2. The browser presents gid (token) as the value of a cookie to the application.
  3. The application extracts and sends gid (token) along with a query to SSO for the user's authentication, the user attributes, and so forth.
  4. SSO responds to the application with that information—for example, the authentication scheme, the resources the user can access, and the user's ID and full name. The application in turn sends that information to the browser.
  5. The browser again presents gid (token) as the value of a cookie to the application.
  6. The application allows user access, taking into account the specifics relayed by SSO in step 3.

Figure 1:

[[Image:]]


Policy AgentThe Policy Agent offers a basic scheme for managing Web access in SSO. As a first step, we can install the Policy Agent in the application's runtime environment, such as a Web server or an application server. See Figure 2 illustrates the process flow.

[[Image:]]Figure 2:

Retrieved from "http://www.leatherlink.net/bsg-kbase/index.php/Single_Sign_On"
Personal tools