Single Sign-On Access Management A Technical Framework on Access Management Systems

Transcription

1 Single Sign-On Access Management A Technical Framework on Access Management Systems Polaris Software Lab Ltd., 766, Anna Salai, Chennai, INDIA

2 Single Sign-On Access Management Service This paper gives a brief overview of SINGLE SIGN-ON SERVICE (SSO). It contains a definition of SSO, business and technical necessities of providing a SSO service and benefits that accrue to an organization, which provides this service. The paper also outlines our development framework for providing a SSO service. What is Single Sign On Service? Single Sign On (SSO) is the primary part of a larger system of Access Management of online resources available through the Internet, Intranet or VPN and various mobile devices. SSO provides customers, employees, suppliers and other stakeholders of an organization with a single point of access to information made available by it in electronic format. It allows users to access information residing on multiple systems without having to sign in for each system that is accessed. SSO traditionally has been considered a security technology. It addresses two primary concepts of security- authentication and authorization. Authentication is the process by which the system verifies the user's identity (who you are), while authorization determines what that user is allowed to do (what can you do?). Why Single Sign On Service? Business Imperatives Relationship Managers and bankers can access customer information locked in multiple systems without having to sign-in for each system thus reducing time spent on searching for information. It does away with the headache of password administration. Users can change access passwords of any system and it automatically gets updated in the database thus allowing users to avoid the trouble of remembering each password while allowing them to change passwords as often as they want to prevent unauthorized access. Financial Imperatives The value of SSO cannot be argued with, but its costs and implementation time can skyrocket for large companies with heterogeneous environments and different users needs. A survey by the Securities Industries Association of Washington DC found that users spent on average 44.4 hours a year just "logging in". With SSO they would have spent only 11.1 hours. To quantify, this would represent a saving of over $800,000 for a 1,000-users company. 1 SSO helps reduce annual security management costs. Novell estimates that a 10,000 person organization with the average employee requirement to access five+ password-protected applications would expect to save more than $12 million over three years, with a return on investment in six months. Technology Imperatives It allows savings in IT resources by allowing secure access to legacy systems deployed in a web environment without any changes to the original application. 1 Source: Securities Industries Association, Washington DC USA 1

3 For a network administrator, security management becomes a simpler task as work gets concentrated on one single system rather than having to administer multiple systems. How Do we Implement Single Sign On Service? 1 User enters name and password 4 Directory Server LDAP Server provides ACLs to allow authentication server to determine authorization levels Authentication Server Web Server Application Server and Legacy Systems 2 Client sends name and password across the network using SSL encryption 3 Server uses password to authenticate user 5 Server authorizes client to access application servers Connectors 6 Web Server accesses application server to fulfill client requests The SSO approach centralizes the authentication process. Authorization can be managed either centrally or on the target systems. An in-between approach to authorization can be taken by centralized "security administration", which centralize the administration of user privileges but leave the actual authorization process to target resources. In a browser based client-server environment, either deployed on the Internet or through an Intranet, all requests are routed through an authentication server. On accessing a portal either through the Intranet or Extranet, the user is prompted with a log in screen. The user enters a username and password to login to the authentication server. The client sends the username-password to the authentication server using a 128- bit encrypted SSL connection. The server verifies the user with this user id and password and extracts and stores all the login details (username, passwords and authorization levels for each allowed server) in cache from a directory server that stores this information in an encrypted ISAM file. On authentication, the user is presented with a standard or customizable page with links to only those systems, which the user is authorized to access. The links from within the page direct the user to other systems, which need to authenticate the user. For this, the server specific (each corresponding to a particular link) login details stored in cache for each user session is supplied to the remote server and allows the user to connect to these systems without having to actually fill in login details. For this purpose, the application server will access remote systems through connectors. These connectors are messaging applications 2

4 Our Experience (like IBM MQ Series) used to connect two systems running on disparate platforms either asynchronously or in real time. It is also possible to adapt this system for a mobile computing environment without any changes to the framework. Sun s J2EE provides excellent support for such application development through its EJB framework. Session beans are used to cache login details and servlets are be used to present information in customized format. EJB s support for diverse platforms, multithreading, transaction management and persistence provide the ideal environment for developing such distributed component application systems. Polaris Software Lab has worked with leading multinational banks over the last few years in jointly developing security system, deployed across the world. A case study of a particular multinational bank is given here. Business Challenges The bank had acquired a diverse array of technology infrastructure over the years and operated on a disparate range of platforms, which included mainframes, packaged applications like SAP and Siebel and custom developed applications on both open and proprietary architecture. Its core banking system sat on such a diverse platform and as banking operations globalized, it was becoming increasingly difficult to provide secure and seamless access to information required by bankers to service their clients in a better and more cost-effective manner. A bigger challenge for the bank, with a considerable private client base, was to provide single window access to all client related information, which typically resided on different systems (IBM/VAX/UNIX/WIN-NT etc) residing in different geographies. The technology challenge here was to develop a system that would connect to each of these systems (supporting more than 40 products) and pool data from multiple systems into a single screen apart from providing order generation and workflow automation. Solution We worked with our client to develop a security system that would provide a single sign-on (SSO) service, secure data exchange and call third party systems from within this common interface. The system could operate in three environments -Web based thin clients, proprietary client shells and Unix. While web based clients would operate through standard browsers, proprietary applications needed a custom designed client shell and Unix systems would operate through the Telnet prompt. While running applications through this system that connected to remote-hosts, neither the desktop needed to be replaced nor the host applications currently running at the desktop. The problem of communicating with different systems, like Siebel, Oracle that was required to invoke third party applications, was solved by joining them with the security system through message-oriented-middleware based connectors. Main Features of the System Common Front End Security Server. This provides: Authentication and authorization services to applications and Administration services to CFE Administration tools. 3

5 Security Server Administration Tools This includes a GUI based tool for managing and administering security services, and batch tools for menu definition and entitlement definition. Security Server - Application Interface Public API calls to security server for performing authentication and authorization checks. Single Sign On to all applications. Application Components 1. Tickets are a collection of information (the login details), which are required to authenticate a client to a server. This included username, password, time stamp, expiry date and ticket class (authorization levels) 2. Ticket Extensions are extra information that are stored by specific servers for their particular use without impeding the interoperability of a ticket. 3. Authentication agents run on the application web servers/application servers. The authentication agents perform the following tasks: Verify the user's ticket before allowing application requests to proceed, Validate users' passwords (or other identification information), and Perform access control decisions on behalf of the application server code. Authentication Agents uses Client API. For NT implementation of Client API, JAVA APIs are used. Similarly, for Unix implementation of Client API, C libraries are used. API signatures were common across all supported products, even though their implementations are different. 4. Common Login is a Java applet, which allows the user to securely login and launch all entitled applications from a single screen. It uses the Client API (Java) to login to the authentication server. After successful login, this applet retrieves information on all entitled applications for that user and displays them as icons. Thin client, thick client and terminal emulation applications will all be shown in this screen. 5. Connectors are message-oriented-middleware (like IBM MQ or MSMQ) that connects the security system with a number of backend systems. Such messaging system could be either asynchronous or real time. Program 1 Program 2 Queue Interface Messages Queue Interface Queue Manager Queue Queue Queue Manager Messages How do two systems communicate by messaging each other 4

6 Deployment Environments 1. Thin Client Applications Thin-client applications are launched in a new browser window, and the window will point to the application's URL. The authentication ticket is set as a cookie, and is available to the application server. Web Common Login Client API (Java) Security Service (CitiSAFE/4C/other) Ticket Component Launch application Application (Thin Client) Application request & Ticket Authentication Agent (Verify ticket) Application Server (Web) 2. Thick Client Applications The Web Common Login launches thick-client applications as separate processes Web Common Login Client API (Java) Security Service (CitiSAFE/4C/other) Ticket Component Launch application Application (Thick Client) Client API Application request & Ticket Client API Application Server Verify ticket 3. Telnet based Applications In Telnet based applications, the client will send the ticket to the server instead of Id/Password. On clicking on a Telnet based application, Web Common Login will launch the Web Telnet applet and pass the ticket to it, along with the destination URL (which will point to the Authentication Server for ticket verification). 5

7 Some Sample Screen Shots 6

8 About Polaris Software Lab Polaris Software Lab is a Chennai, India based software solutions provider in the banking, financial services and insurance space. Polaris is a SEI CMM Level 4 company and in 2001 it became the first company in the world to be SEI CMMI certified. It has been ranked among the Forbes 300 fastest growing small companies in the world. It has been growing at over 100% year on year for the last three years. We have offices and subsidiaries in 15 countries across the world. For more information, please visit us at or mail us at chennai@polaris.co.in. 7

9 How to contact us To obtain further information about the services offered by Polaris Private Banking Practice, please contact us on: Locations POLARIS SOFTWARE LAB LIMITED Polaris House, 713, Anna Salai, Chennai INDIA Phone: Fax: chennai@polaris.co.in POLARIS SOFTWARE LAB GmbH Westendstrasse Frankfurt am Main Germany Phone : +49 (0) Fax : +49 (0) germany@polaris.co.in POLARIS SOFTWARE PTY LTD Level 10, 109 Pitt Street Sydney NSW 2000 GPO Box 5398 Sydney NSW 2001 Ph: Fax : australia@polaris.co.in POLARIS SOFTWARE LAB (INDIA) LTD 38750, Paseo Padre Parkway Suite, A7, Fremont, California USA Phone : , Fax : fremont@polaris.co.in POLARIS SOFTWARE LAB PTE LIMITED High Street Center 1 North Bridge Road Singapore Phone: Fax: singapore@polaris.co.in POLARIS SOFTWARE LAB LTD Ground Floor, Dubai Internet City P.O.Box Dubai UAE Tel dubai@polaris.co.in POLARIS SOFTWARE LAB S.A. Passage Max-Meuron 1 CH-2001, Neuchatel, Switzerland Phone : Fax: swiss@polaris.co.in POLARIS SOFTWARE LAB IRELAND LIMITED 19 Lower Baggot Street Dublin 2 Republic of Ireland Ph: (1) , (1) Fax : (1) ireland@polaris.co.in POLARIS SOFTWARE LAB LTD 100, Longwater Avenue GreenPark, Reading RG2 6GP, UK Phone : Fax : uk@polaris.co.in Disclaimer The information contained herein is of a general nature and is not intended to address the circumstances of any particular individual or entity Polaris Software Lab Ltd. This publication was issued by Polaris Private Banking Practice as part of its continuing programme of addressing the information technology issues facing the industry. Confidential 1