Single Sign-On Systems - TKK - · PDF fileHelsinki University of Technology Telecommunications...

Helsinki University of Technology Telecommunications Software and Multimedia Laboratory Research Seminar in Telecommunications Business I T-109.501

Single Sign-On Systems

19.11.2002

Tomi Määttänen 45342K

Helsinki University of Technology 2/21 Research seminar in Telecommunications business I, T-109.501 Single Sign-On Systems - Tomi Määttänen 45342K 19.11.2002

1 INTRODUCTION................................................................................................3

1.1 ABOUT THIS PAPER..........................................................................................3 1.2 SINGLE SIGN-ON SYSTEM FEATURES OVERVIEW ..............................................3

1.2.1 Single sign-on functionality and auditing ..............................................4 1.2.2 Authentication with different security levels..........................................4 1.2.3 Centralized security policy and user management ................................5

1.3 WHY SINGLE SIGN-ON? ...................................................................................5 1.3.1 Single sign-on benefits ...........................................................................7 1.3.2 Single sign-on problems.........................................................................7

1.4 DIFFERENT LEVELS OF SINGLE SIGN-ON ..........................................................8 1.4.1 Intranet single sign-on ...........................................................................9 1.4.2 Extranet single sign-on ..........................................................................9 1.4.3 Internet single sign-on ...........................................................................9

2 SINGLE SIGN-ON ARCHITECTURE...........................................................10

2.1 GENERAL LEVEL ARCHITECTURE ..................................................................10 2.2 MESSAGE LEVEL ARCHITECTURE ..................................................................11

2.2.1 Tickets ..................................................................................................11 2.2.2 Initial authentication............................................................................11 2.2.3 Single sign-on authentication ..............................................................12 2.2.4 Logout ..................................................................................................13

3 SINGLE SIGN-ON DEPLOYMENT...............................................................14 3.1 BEFORE DEPLOYMENT...................................................................................14 3.2 THE ACTUAL INSTALLATION .........................................................................14 3.3 WEB AGENT INSTALLATION ..........................................................................15

4 SINGLE SIGN-ON MARKETS .......................................................................17 4.1 SINGLE SIGN-ON MARKETS AND PLAYERS .....................................................17 4.2 MARKET TRENDS ..........................................................................................18 4.3 COMMERCIAL BUSINESS CASE.......................................................................18

5 SUMMARY ........................................................................................................19

6 REFERENCES, LINKS AND ABBREVIATIONS........................................20 6.1 REFERENCES .................................................................................................20 6.2 ABBREVIATIONS ...........................................................................................21


1 Introduction

1.1 About this paper

This paper is written for Helsinki University of Technology and Research seminar on telecommunication business. The goal of this paper is to describe the idea and technology behind single sign-on systems (SSO) that work in web environment, and discuss its deployment issues, and markets. The following topics will be covered: - How does the typical SSO system architecture work - What are the factors must be considered when deploying SSO system - SSO market, growth prospects and main players - One commercial business case It should be noted that this is only descriptive and introductive document for the seminar presentation. This paper doesn’t help developers to implement and administrators to deploy single sign-on systems and it doesn’t contain full details of single sign-on technologies. Only one specific type of single sign-on system architecture will be introduced, though it represents architecture in a general level that is widely common solution in current commercial single sign-on systems.

1.2 Single sign-on system features overview

Single sign-on system, later SSO system, is a solution that brings different features to the IT infrastructure where it will be deployed. It enables different issues involving authentication, authorization and auditing (AAA), for most important factors being:

- Single sign-on functionality and auditing - Authentication with different security levels - Centralized security policy and user management (authorization)


User User managemanage--

mentment

AuthoriAuthori--zationzation

AuthenAuthen--ticationtication

AccountingAccounting

TrendTrendanalysisanalysis

BillingBilling

AuditAuditCost Cost

allocationallocation

Figure 1 The key domains of single sign-on systems

1.2.1 Single sign-on functionality and auditing The most obvious feature is of course the actual single sign-on functionality. Single sign-on is a concept where in contrast of users having multiple user id and password pairs or other authentication methods to different services and applications, they can now access all those applications and services through a single point of entry (The Finnish Centre for Technical Terminology, 2002b). The auditing or accounting part takes care of logging, auditing functions and possibly gathering billing information. SSO systems can usually provide reporting facilities so that all significant security events (such as user authentications, authorizations, etc.) can be tracked and logged for administrator analysis. The value of this kind of security feature can be significant when all or most of the organization systems are working in a SSO system.

1.2.2 Authentication with different security levels Authentication is a method by which the identity of a user, an application, a device etc. is identified by a service provider. Authentication is usually followed by authorization (The Finnish Centre for Technical Terminology, 2002a). In a SSO system it is possible to require specific authentication methods for different applications and for different users. SSO system can usually enable single sign-on user authentication using one or a selection of different authentication methods like username and password, one-time passwords (Haller et al. 1998), smart card (or other client certificate), or SMS messages


(plain text or signed with STK application). The task is to choose authentication methods that best serve the needs of the application or user level in question. Security

Light Mediu High

Digitally signed SMS Symmetric or (PKI)cryptograp

Smart Card etc. Client Certificate (PKI)

Traditional Username and Password

Plain SMS (+ PIN)

One-Time Passwords generated a mobile devic

Software Client Certificate (PKI)

Figure 2 Different levels of authentication

1.2.3 Centralized security policy and user management SSO systems enable centralized security policy and user management for different applications. Authorization is the concept that covers partly these issues. Authorization is the process of dictating who is to use which resources, and under what kind of conditions.

The SSO system administrator is able to control passwords and authorization information related to different users, user groups and applications. Part of the user management tasks can also be managed in a distributed set-up if necessary, e.g. by persons that are responsible for other organization unit authorization.

1.3 Why single sign-on?

The features described in chapter 1.2 gives some obvious reasons why single sign-on system deployment can be justified. The discussion in this chapter will deepen the subject. Single sign-on is one key part in data security, which can at the same time increase user experience, ease administration and save costs. Users are today overwhelmed by having to memorize a growing number of user-id and password pairs, as they use various network services and applications. This fact


can even mean that users don’t start using new services at all or use them only a few times. Numerous users who have forgotten their password also continuously contact support services and helpdesks, hence generating unnecessary costs and dissatisfaction. Usability and deployment issues are often in clear contradiction to the security aspects. However both these areas can be answered and served well utilizing single sign-on systems. Yet, the authentication security and trust levels are favourable both for the end-user and for the administrators of the system. SSO systems can offer fast and efficient deployment and provide efficient enabling tools and information for personalization of web-services, web-application like e-commerce and m-commerce applications. Corporations and other organizations today see security as a ‘must’ – especially for those who want to create and maintain their confidential relationships with customers, partners and subcontractors. User authentication is a key success factor to enable e-business. Strong authentication is not considered an additional security insurance-like feature anymore, but rather an enabling IT infrastructure part that plays an important role when building foe example business relationships in networks. And why are we here? According to Hursti (1997) (Figure 3), there are growing knowledge requirements concerning threats towards digital information. In the figure there is seen a complexity of networked applications that require security and the complexity of the security solutions. To cope with these complex systems the organizations need tools to manage the complexity. Single Sign-On SSO is an answer to these needs.

Figure 3 The Development of the Security Business Segments as a Response for the Increasing

Needs of Networked Applications (Hursti 1997)


1.3.1 Single sign-on benefits

SSO systems can offer user authentication and single sign-on capabilities to any web-based application. Some of the most important benefits provided by SSO systems are the ability to centralize user management, authentication, authorization and auditing, as well as to utilize many different authentication methods. Through SSO system capabilities, users may authenticate across multiple applications on a web environment, without encountering a separate log-on screen for each application thus allowing access to all organization assets with a single ID and password combination or with other centralized deployed authentication method.

When organizations adopt a centralized security infrastructure, they eliminate the need for application-specific security implementations and security business logic, thereby reducing development and maintenance costs from other web applications. SSO systems make applications development simpler, as the developer can write code that relies on the SSO systems’ user and group management features, rather than developing unique user management systems for each application.

SSO systems can also reduce the costs of IT-administration as well as other user-data administration costs. They reduce the number of help desk calls from users wanting password resets because they forgot a password. It also makes it simple to disable a terminated user's access to all organization applications by disabling a single account.

SSO systems enable organizations to centrally manage all user authentications and all user access control following organizational-wide security policies. SSO systems enable e.g. that an application, which provides users with some critical information, may require stronger authentication schemes than other more casual applications. That is, authentication can be deployed based application, user and content. The simplest use of SSO system authentication might simply concern access to web or extranet pages holding some confidential information.

1.3.2 Single sign-on problems

Is there a downside of SSO that, once you have signed on, you can access every application? This means that once a bad-willing person has signed on he can access everything, whereas if you didn’t have SSO, he would just be able to access a part of the network. So the authentication at the ‘front door’ has to be very good for SSO to be widely accepted.

This is an obvious and often asked question. SSO will not be a downside and lower the security IF the organisation security policy is defined properly to


prevent unauthorized access to important information without proper level of authentication. This means for instance that every application should be configured in the SSO system so that it meets the appropriate security level, which is required for user authentication to that particular application. Due to the centralized management and administration features, changing user credentials or closing down a user account e.g. in case of theft or misuse becomes instantly effective everywhere. If the security levels are defined properly and a bad-willing person has for some reason got some other persons users username and password, and he is trying to access an application which requires higher security level (for example smart card authentication), then the SSO system will ask for smart card authentication before proceeding and letting the bad-willing user enter the application. Hence, SSO is as secure or more secure as before the SSO implementation, and still is more user-friendly and cost-efficient when compared to trying to manage without it.

Another risks or possible problem is single point of failure: usually SSO systems provide access through a single point of entry. Aren’t there attacks like DoS (Denial of Service) that could bring SSO systems to its knees? Or what if the authentication service fails? Comprehensive SSO systems provide high availability so that single point of failure in the system doesn’t affect the whole system behaviour. SSO systems can offer high scalability, availability and load balancing features that reduce the risks and effects of these problems.

1.4 Different levels of single sign-on

To have another view on the single sign-on systems subject, look at Figure 4.

Figure 4 Different levels of single sign-on


1.4.1 Intranet single sign-on

Intranet SSO is a single sign-on system, which is deployed in an organization or in a community. In this case the SSO system provides access only to on authority like corporate, community or some other organization.

1.4.2 Extranet single sign-on Extranet SSO is a single sign-on system, which is usually deployed between organizations. As we will see in the Chapter 4.1, the most of the SSO system markets is concentrated on extranet SSO. This is mostly because of that with an extranet SSO solution organizations can cover also intranet SSO related issues. Extranet SSO usually means that there are different security domains and user directories that work within one single sign-on system or with multiple single sign-on systems that work together. Federated single sign-on is the concept name.

1.4.3 Internet single sign-on

Internet SSO is a single sign-on system, which is deployed in the whole Internet. This kind of single sign-on system can be also called as global single sign-on. The most know global SSO system is Microsoft .NET Passport. It is a suite of Web-based services that provides users with single sign-in (SSI, Microsoft term for SSO) and fast purchasing capability at participating sites (Microsoft 2002a). The Liberty Alliance project, which represents another global single sign-on, will provide a “federated solution for network identity - enabling ubiquitous single sign-on, decentralized authentication and open authorization.” Sun and Nokia are behind Liberty Alliance, among other players (Liberty Alliance Project 2002).


2 Single Sign-On Architecture

This chapter describes how one SSO system works. There are two levels described: general level and message level. Message level describes more specific the actual message flow between different entities. The architecture described is a specific type of single sign-on system architecture and it represents an architecture model in a general level that is widely common solution in current commercial single sign-on systems. Different implementations differ a lot in message level architecture.

2.1 General level architecture

Typically SSO system is divided in two parts: SSO server and application components, also called as web agents (Figure 5).

USER DIRECTORY

USER DIRECTORY

APPLICATIONOR

WEB SERVER

APPLICATIONOR

WEB SERVER

WEB BROWSER

APPLICATIONOR

WEB SERVER

APPLICATIONOR

WEB SERVERAPPLICATION

OR WEB SERVER

APPLICATIONOR

WEB SERVER

WEB AGENT

AUTHENTICATION DEVICE

SINGLE SIGN-ONSERVER

SINGLE SIGN-ONSERVER

Figure 5 Typical single sign-on system architecture overview

SSO server keeps track of the authenticated users, the applications the users use and it works together with web agents to handle initial authentication and single sign-on procedures. SSO server gets the user information from user directory and passes the username and other user specific user information to applications. SSO server and user directory communicate usually with LDAP. Web agents are small HTTP filter-modules attached into application or web server. They control the HTTP-requests that end-users send to web/application server and initialize the authentication if the end user hasn’t been authenticated


yet. They make sure that only the authorized users’ HTTP requests are passed to the applications. Web agents communicate with the SSO server through the end-user web client using ordinary WWW technologies; HTTP redirects, URL query strings, and Cookies. When considering the end-user requirements, they only need a HTTP browser that supports SSL (Secure Socket Layer protocol) and JavaScripts.

2.2 Message level architecture

2.2.1 Tickets Encrypted tickets work as tickets to enter to applications and SSO servers. To implement both single sign-on authentication to all applications that work within one single sign-on system, and a single application level sign-on, there are two types of tickets: server tickets and agent tickets. Server tickets are SSO server specific tickets which grant access to whole single sign-on system. Agent tickets are web agent specific tickets which grant access to one web server or web application which works behind one specific URL. The tickets are encrypted using symmetric block cipher Triple-DES (3DES), with Cipher Block Chaining (CBC) mode, and only the entities possessing the key, usually only web agents and SSO server, are able to read the information. Message integrity is accomplished using cryptographic SHA-1 digests of the exchanged information. The digests are part of the ticket, and thus encrypted when exchanged in the network (Nykänen 2002: 35).

2.2.2 Initial authentication

End-user enters first the web application URL to his browser (Figure 6). Then web agent #1, which is attached to web application, catches the HTTP-request and notices that there is no valid agent ticket in the browser. Browser is redirected to SSO server which checks first if there is a valid server ticket. If not, the SSO server opens a secure SSL connection with the browser and authenticates the user. Authentication method could be configured based on user preferences, application preferences or based on any other data. After successful user authentication the SSO servers generates both the encrypted server ticket and encrypted application ticket. Application ticket contains always some information about the user, usually user name that the application can make sure who the user really is. SSO server will then redirect the browser back to the original web application. Web agent catches again the HTTP-request and notices now that there is a valid


application ticket. Web agent decrypts the ticket and generates a cookie for the browser. The cookie contains now the information from the ticket like username and application specific parameters. Now the redirected HTTP-request will be passed through the web agent till to the web server, and user can normally start user the web application.

2.2.3 Single sign-on authentication

Now the user wants to access another web application during the same session. He enters another URL and now web agent #2 catches the HTTP-request (Figure 7). Again, there is no valid application ticket and the browser is redirected to the SSO server. SSO server check first if there is a valid server ticket and now it is found.

Figure 6 Sequence diagram of initial authentication procedure (Stenius 2002)


Figure 7 Sequence diagram of authentication procedure with single sign-on

2.2.4 Logout There are three ways to log out from this SSO system. The credentials, server ticket and application tickets have a limited lifetime. If user’s server ticket has expired, new application tickets can no longer be acquired without interactive authentication. Thus, by the time the server ticket and application tickets have expired, the user will be logged out. The cookies used by the SSO server are by default session cookies. This means that they are not stored permanently to a hard drive or anything, and are removed from computer’s memory when the browser application is closed. As long as only session cookies are used, a simple way to log out of the system is to close the browser. There is also a third way to log out of the system. The server ticket of the user contains a list of applications the user is logged in, and information on how to log out of each specific application. Since SSO system credentials are at the end stored in cookies bound to the specific domains and paths where the web agents reside, the logout can be accomplished by removal of all of these cookies. This is accomplished by a HTTP request that removes the cookies (Nykänen 2002: 43-44).


3 Single Sign-On Deployment This chapter will shortly introduce the different factors that must be considered when deploying SSO system.

3.1 Before deployment Before the installation the organization’s IT infrastructure must be reviewed in order to plan and specify how SSO system will be used in the organization. If the organization security policy is defined appropriately, it will give most of the guidelines for the SSO system deployment. Some of the most important things that have to be decided are: - Is the SSO server going to be installed in the organization premises or is it

going to be used a remote service? - Is there a centralized user directory or database ready to use or is it going to

be created separately as part of the deployment? - What users and groups are there in the organization? - What are the web applications and web pages or content to be secured with

SSO system and what technology does those applications and web pages use?

- Are the current web applications using some authentication method and do they use common platform specific methods for getting the user information and other parameters?

- What authentication methods will be used with the SSO system? - What users can access to what applications? - What authentication method(s) are required for the applications? - Are there any non-web applications that are going to use SSO system?

After this initial review there will be established a plan which covers at least these issues.

3.2 The actual installation Thanks to SSO system architecture and easy web agent deployment, the actual installation is usually very straightforward and an easy task to accomplish (Figure 8). In deployment two things are needed: SSO server installation and web agent configuration. If the SSO server will be used as a service, then only web agent installation is needed.


To do that we also need to know what kind of applications (and server which runs them) are going to be part of the SSO system because the web agents are platform specific. Normally the SSO server will be installed in DMZ. The idea of DMZ is to have a protected area for the external services. That usually means that there are double-firewalls against the Internet. The organization side firewall will enable the updates to the WWW-servers, but no other traffic. The outbound firewall will protect the services from getting vandalised or intruded from outside.

11 22 33

GET READY

SSO server installation

OR

SSO servercervice

configuration

SET

Web Agent configuration

AND/OR

Application(s)configuration

GO

Web Applications and services

are using SSO system

Figure 8 SSO system deployment can be very straightforward

3.3 Web agent installation

This chapter describes how web agents are configured in Microsoft IIS web server. All web agents have same parameters, which typically are:

- Application ID - Secret between application and SSO server - SSO server’s URL

First the web agent has to be installed and the parameters above have to be set. After successful installation, login information is transmitted from web agent (ISAPI filter in this case) to the application in "ServerVariables" variable named as REMOTE_USER. ISAPI filters are programs that respond when the Web server receives an HTTP request (Microsoft 2002b).


If JavaScript is in use in ASP-code, the login id can be called with function Request.ServerVariables("REMOTE_USER"). Below is ASP-code that prints user’s user ID in a browser. Applications can use this example to get the login id to the application with JavaScript. <% @language="javascript" EnableSessionState=False %> <h1>Welcome!</h1> <p>You have been authenticated as <b><%= Server.HTMLEncode(Request.ServerVariables("REMOTE_USER")) %></b>.</p>

This is a web server specific standard to pass user information to web applications, and all other web agents use same kind of platform specific standards.


4 Single Sign-On Markets

This chapter discusses briefly about the current SSO system market, growth prospects and main players. There is also one commercial business case description.

4.1 Single sign-on markets and players

The most activity of SSO markets has been seen on solutions for managing user access to e-business web sites. The markets are also called as ‘extranet access management’ (Pescatore 2002). According to Pescatore (2002), there were 11 main players in January 2002 (Figure 9): Netegrity, IBM, RSA Security, Oblix, Entrust, Novell, Open Network Technologies, Entegrity, Baltimore Technologies, Vasco and Wipro.

Figure 9 Key players in Extranet Access Management (EAM) market (Pescatore 2002)

Market is described as immature and volatile. Netegrity is clearly seen as market leader but it faces hard competition from vendors like IBM especially. Netegrity has over 400 SSO system customers (Allan 2001).


4.2 Market trends

Single sign-on systems are becoming more and more common all the time. The main drivers for their success are evolving authentication methods, standardized application interfaces, the need of making IT systems more effective in heterogeneous IT infrastructure and because of that, the security needs are higher every day. One clear trend outside business world is that consumers want also single sign-on. To be able to use a single user ID and password in different web sites is very important to 54 percent of the online users. More than 80 percent of online consumers register with web sites occasionally or frequently, so they need to remember multiple user ID/password combinations. (Litan 2002)

4.3 Commercial business case

VVO is a Finnish limited company providing housing services. VVO provides rented accommodation, right-of-occupancy homes and part-ownership homes. VVO has about 500 employees. VVO has deployed a SSO system for the intranet and extranet services. The system enables the staff to authenticate and work securely as remote users through www-browser. The system consists of SSO server and web servers that have web agents installed. The SSO server resides in DMZ (Demilitarized Zone). Authentication to VVO system is possible with different authentication methods, such as traditional password, one-time passwords, smartcards and SMS. In this way the solution offers versatile possibilities to deploy a security policy that takes into consideration variable needs in the organization as well as users’ different needs and expectations. In addition to strong user authentication, SSO system enables single sign-on between different technology platforms and applications. SSO system makes it possible for VVO employees to authenticate themselves to intranet applications, such as web-based e-mail remotely. Before, the applications were accessible only within VVO’s own premises. With the single sign-on solution VVO can offer its interest groups and customers the possibility to exploit new services in a secure and user-friendly way with optimal solution options.


5 Summary

Single sign-on systems are solutions that permit an end-user to prove his/her identity in order to obtain access to multiple web-applications. SSO systems support also several authentication methods ranging from password-based identification to certificate and possible to SMS, smart card or other authentication methods. Besides usability issues, the current technological and economical trends argue for SSO system deployment. The continuously growing market is a clear indication that SSO will take its place. Global single sign-on systems like Microsoft Passport and Liberty Alliance increase people consciousness about the benefits of SSO systems, and will lead to a situation where commercial SSO systems will interoperate with these global SSO systems. This trend is not technology-driven, but based on real needs and benefits. The bottom issues is that, if properly deployed, SSO will increase usability AND security, both in the same time.


6 References, links and abbreviations

6.1 References Allan, Ant. (2001) Netegrity SiteMinder Extranet Access Management (EAM) Product. Gartner. Hursti, Jani (1997). Single Sign-On. 18.11.2002 <http://www.tcm.hut.fi/Opinnot/Tik-110.501/1997/single_sign-on.html> Liberty Alliance Project (2002). 18.11.2002 <http://www.projectliberty.org/> Litan, A. (2001) Microsoft Passport: Build It and They Will Haltingly Come. California Lutheran University Microsoft (2002a). .NET Passport Overview 17.11.2002 <http://www.microsoft.com/netservices/passport/overview.asp> Haller N, Bellcore, C. Metz, P. Nesser, M. Straw, Bellcore (1998). A One-Time Password System. RFC 2298 The Internet Society. 18.11.2002 <http://www.faqs.org/rfcs/rfc2289.html> Microsoft (2002b). Installing ISAPI Filters 17.11.2002 <http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/core/iiwarndg.htm> Nykänen, Toni (2002). Secure Cross-Platform Single Sign-On Solution for the Current World-Wide Web Pescatore, J. Extranet Access Management 2H01 Magic Quadrant. Gartner Stenius, Petteri (2002) Unpublished requirement specification, Innopoli, Espoo The Finnish Centre for Technical Terminology (TSK). 18.11.2002a <http://www.tsk.fi/termitalkoot/> The Finnish Centre for Technical Terminology (TSK). 18.11.2002b <http://www.tsk.fi/termitalkoot/>

http://www.microsoft.com/netservices/passport/overview.asp

http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/core/iiwarndg.htm

http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/core/iiwarndg.htm

http://www.tsk.fi/termitalkoot/

http://www.tsk.fi/termitalkoot/


6.2 Abbreviations 3DES Triple-DES AAA Authorisation, Access Control, Accounting CBC Cipher Block Chaining DMZ Demilitarised Zone DoS Denial of Service EAM Extranet Access Management HTTP Hypertext Transfer Protocol LDAP Lightweight Directory Access Protocol OTP One-Time Passwords PKI Public Key Infrastructure SAML Security Assertion Mark-up Language SHA-1 Secure Hash Algorithm SMS Short Message Service SSI Single Sign-In SSL Secure Sockets Layer SSO Single Sign-On STK SIM Toolkit URL Universal Resource Locator WWW World Wide Web

Single Sign-On Systems - TKK - · PDF fileHelsinki University of Technology Telecommunications...

Documents

Transcript of Single Sign-On Systems - TKK - · PDF fileHelsinki University of Technology Telecommunications...