WEB BASED SINGLE SIGN-ON

Problem Statement Increasing number of independent products on the web open security holes and interrupt the customer experience. The company comes up with new websites for new offerings. Independent sites and products make it hard to provide a seamless experience to users and they may leave right away when they see they have to log in one more time. To fix this problem, a SSO solution could help better secure the different applications as well as to provide a seamless experience to users to navigate between the applications by logging in just once.

Definition - SSO Single sign-on (SSO) is a session/user authentication process which allows a user to log in once in order to access multiple applications. Single sign-on (SSO) is a session/user authentication process that permits a user to enter one name and password in order to access multiple applications. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session.

Advantages Convenient to keep one user name/ password. Reduces phishing success. Reduces support efforts. Centralized reporting for compliance adherence. Easier to market future products. Reduces phishing success, because users are not trained to enter password everywhere without thinking. Reducing password fatigue from different user- name and password combinations Reducing time spent re-entering passwords for the same identity Reducing IT costs due to lower number of IT helpdesk calls about passwords and infrastructure cost Security on all levels of entry/exit/access to systems without the inconvenience of re-prompting users Centralized reporting for compliance adherence. Helps business to bring multiple system into one umbrella. It allows business to move multiple applications towards the portal strategy. Portal lets user to authentication once and then based on authorization system allows them to navigate to other applications.

Disadvantages Single point of failure. Implementation complexity. Lack of flexibility. As single sign-on provides access to many resources once the user is initially authenticated, it increases the negative impact in case the credentials are available to other persons and misused. Therefore, single sign-on requires a secure authentication mechanism. Because all the various applications need to share the authentication scheme, it lacks flexibility and all the applications need to adhere to the security standards implemented for SSO.

Web- based SSO SSO cookie. Session replication. Cookie transfer: sub- domains. Once logged in to a website, a cookie is stored with its authentication information. Session replication: once logged in to, for example, Amazon.com and chose a book to buy so it's in the shopping cart. I might be on a second browser on a different website and when I come back to Amazon, the shopping cart might be gone (session has timed out), but I may still be logged on (cookie). Multiple domain: mail.google.com vs drive.google.com. Cookie is shared across the domains. If it were google.drive.com since it's in a different domain, it couldn't carry the cookie over.

What is a Cookie? Cookie is - A small piece of data sent from website. It is stored in user's web browser session. Website retrieves the data from cookie, whenever website is accessed. To find whether the user is logged in or not - Authentication cookie. Cookie is intelligent browser object. A cookie is usually a small piece of data sent from a website and stored in a user's web browser so that stored data in the cookie can be retrieved by the website in the future to notify the website of the user's previous activity. Authentication cookies are the most common method used by web servers to know whether the user is logged in or not, and which account they are logged in under.

Cookie Characteristics Session cookie – Disappears when browser closes. Secure - Only available to HTTPS. HttpOnly - Not supported by javascript and other protocol. Domain - Allows to read the cookie by the given domain such as “.yahoo.com”. Path - Location of the cookie. Example - Set-Cookie: SSID=Ap4P….GTEq; Domain=.foo.com; Path=/; Expires=Wed, 13-Jan-2021 22:23:01 GMT; Secure; HttpOnly Following characteristics of cookies are been considered to design cookie based SSO solution Session cookie – Disappears when browser closes Secure and HttpOnly - – Support by HTTP and HTTPS but not any other protocol such as Javascript Domain and Path - It define the scope of the cookie and allows browser to sent the cookie back to the server Path - Scope of the cookie is location of a cookie

Example of Cookie Example of cookie - how does it look like once it gets created at the client browser for example Name, content, Path, send For and Expires

Http Session What is HTTP Session? It is used to associate HTTP client i.e browser with HTTP server. Application server creates the unique identifier to identify HTTPSession Every browser session maintains the state of the user activity via HTTPSession HTTP Session mainly used to associated HTTP client with HTTP server. Server maintains the state of the user activity via browser by associating unique Identifier for each client.

Web based SSO Solution How does Cookie based SSO solution work? User visits the website Server side application checks for cookie If cookie isn’t present, system redirects to logon User completes authentication step Server creates session cookie at the client side with an unique identifier User gets redirected to website home Server checks for a cookie every time before serving any user request. Cookie available in subdomain - “mail.google.com” and “drive.google.com” The cookie based SSO option is for sites that already have an authentication model in place using a browser/login session. Ex - .google.com/ mail.google.com/ drive.google.com User visits the website Server side application checks for cookie If cookie isn’t present, system redirects to logon User completes authentication step Servers creates session cookie at the client side with an unique identifier with main domain such as “.google.com” User gets redirected to website home Server checks for a cookie every time before serving any user request. For example if user navigates between mail.google.com and drive.google.com, the cookie can be read as “mail.google.com” and “drive.google.com” are subdomain

Cont… Server side steps - Application - Authentication system Successful authentication - Create session cookie Domain name (“.mycompany.com”) - Scope of a cookie Path (“.mycompany.com/”) - Request which is served by “.mycompany.com” Cookie value - For example - Base 64 encoded string (Random String + constant) Session data - Stores the session data into the database Given steps are followed at server side while authenticating user and creating SSO cookie. Application communicates with authentication system to authenticate the user Once authentication is successful, create the session cookie so that it Domain (“.mycompany.com”) Path (“.mycompany.com/”) – Enable to read cookie by any request which serves by “.mycompany.com” Cookie value – Set it to unique identifier. For example - Base 64 encoded string (Random String + constant) Store the session data against unique identifier into the database which can be shared acroos multiple domain

SSO Infrastructure Flow

Cookie - Internal Process How internal process look like while creating/working with SSO cookie

Build vs Buy Customized solution (Web based SSO) Off the shelf solution The decision to build your own or buy and off the shelf solution is something many companies face in a lot of software areas, such as CRM, document management, and collaboration tools. A small/medium business is more likely to go with an off the shelf solution as they do not have the resources in personel to build a custom tailored solution. Though this can depend on the field, if there are specific requirements that are not met with off the shelf options, they may go to an outside developer to build their solution. Medium/large and enterprise businesses will have more money and more resources to put in play. They may have a dedicated software development team that can build a solution that fits the business perfectly. And support is a short walk down the hall away sometimes. Off the shelf requires support from the vendor or publisher, and that can mean someone not even in the same part of the world as you, making help that much harder to find. These also have far less customization tools available to the end user, maybe only specific fields, names, layouts, and colors.

Who can use SSO? SSO is a great option for authentication for companies of any size with multiple, diverse applications. Everyone needs authentication for their users Authentication is a concern for any business of any size. The concern and time spent worrying about it can increase with the number applications in use, especially when they are from different software vendors(ie: adobe, microsoft, autodesk, etc...). Different size companies will have different needs for the program, and different levels of support ability. A small company might look at Microsoft's Forefront Identity Manager. It's the easiest for them to deploy and it's familiar to them. But the trade off is customization, though that may not be too much of a concern for smaller companies. Larger companies have different needs and concerns. These factors will play a role in the choice they make.

List of Products Following common products are available for single sign-on implementation In-house (Web based SSO) custom designed solution Microsoft Forefront Identity Manager IBM – Tivoli security access manager Microsoft Forefront Identity Manager – Single Sign on, smart card management, role based Security Access Manager - Enterprise Single Sign-On, Strong Authentication, Password Management product Kerberos is the standard that many of these are built on. It is also available as an open source protocol that you can built your own solution around. *

Cost Analysis In-House (Web based SSO) Solution = $160,800 (no annual support costs, only team labor costs) IBM = $590,000 plus annual support costs Microsoft = $231,000 plus annual support Based on 5,000 user estimate. Software only costs, no additional hardware figured into this estimate These costs are list prices based on 5,000 users. We did not add in any specific hardware that might be need, such as a dedicated server. The in house estimate is based on 5,000 users also. Cost is determined by the pay rates of the team members building the solution 3 (people) * 8 hr * 60 days * 30 $/hr = 43200 (Offshore) >>> 3 (people) * 8 hr * 70 days * 70 $/hr = 117600 (Onsite) >>> Total = 160800 Dedicated hardware for this deployment can vary based on your load, and how you configure it. For the 5,000 users, a multiple server approach with load balancing would add about $45,000 to the cost, including the hardware support.

Cost Analysis cont... Support or Software Assurance comes as an extra line item and is renewed annually. These costs are estimated with the same 5,000 users and are subject to annual changes and increases by the manufacturers In-House (Web based SSO) Solution: $37,440 in yearly labor costs. 3 technicians, average of 8 hours per week for 52 weeks of the year at $30 per hour. IBM: Support costs are $150,000 per year for software maintenance Microsoft: $52,000 per year in software maintenance

Cost Analysis cont... Software maintenance and support costs include new release/version updates, troubleshooting, tech support line, and limited customization. Many times support/maintenance/assurance or whatever it is called includes new version releases during your maintenance period along with dedicated support and troubleshooting lines. Off the shelf options have limited customization that may be offered by the vendor but not fully custom built solutions tailored to your needs

Why web based SSO A smaller footprint for web based. Easy setup We can easily incorporate new apps on the fly The Solution is robust and designed to work with up to 200k users around the world. Flexible installations and configuration Adaptable to your needs

Decision Factors Total Cost of Ownership is the biggest factor - Similar hardware costs, so this is comprised of software, support, and deployment costs. Ease of support - Internal support is important for response time Flexible, adaptable, and customization - We needed something that we could configure to our specs exactly, change on the fly quickly, and add new applications too with little delay. Aligned with the long term Business Strategy - Proposed SSO solution can be easily used across multiple web application Conservative Financial Organisation Environment - Not allowed to utilize any open source library The answers to the question of decision factors will be different depending on your business model and the size, scope of your business. For our company's needs, the project determined these to be the most important to us. And it goes without saying that strong, effective authentication security is one of the top priorities.

Summary Cost effective solution for our problem Customized solution provides an added advantage of in house knowledge Support/ product independent Easy to handle and maintain PCI (Payment Card Industry) compliance requirement In house single sign on provides the advantage of lower TCO, customized and continually adaptable, and in house expertise. Single sign on present our business with the benefit of easier authentication for end users, less IT time spent on username/password support, and the potential for easier future integration with new applications. We also get the knowledge that our security has been improved while making the end user experience and workflow much easier and more productive. The cookie based solution is easier to implement for our developers and easier to support for our technicians. It will also allow us to add new applications and portals to the single sign on process more smoothly.

Questions? Thank you!