1. WEB BASED SINGLE SIGN-ON

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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 :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

9. 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

10. 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.

11. 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

12. 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

13. SSO Infrastructure Flow

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

15. 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.

16. 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.

17. 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. *

18. 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 = (Offshore)
>>> 3 (people) * 8 hr * 70 days * 70 $/hr = (Onsite)
>>> Total =
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.

19. 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

20. 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

21. 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

22. 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.

23. 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.

24. Questions?
Thank you!