Diplomarbeit. Single Sign On In Web Service Scenarios

Diplomarbeit Single Sign On In Web Service Scenarios Joachim Götze Juli 2004 Betreuer: Prof. Dr. Müller Dipl. Inform. Markus Hillenbrand Fachbereich Informatik AG Integrierte Kommunikationssysteme TU Kaiserslautern Postfach 3049 67653 Kaiserslautern

Abstract Web Services have the capability to provide all kinds of services to their clients. Without any knowledge of the implementation, every client can use a Web Service. The Hypertext Transfer Protocol (HTTP) is one of the protocols used to transmit SOAP messages, the communicational basis of Web Services. If there are Web Services that are not only used for local purposes, security cannot be ensured by using a standard corporate firewall, because every communication will use the same HTTP port and a firewall is not capable of distinguishing between the clients that are allowed to use a Web Services and those that are not. In order to secure such a Web Service infrastructure a different approach has to be used. The objective of this diploma thesis is to build an authentication infrastructure that supports single sign on and federations of trust on the basis of Web Services. Single sign on allows a user the easy access to all resources in a network without the need to enter a password several times, but enter it only once. A major advantage of federations of trust is the enhancement of dynamic interaction of different trust domains. Therefore these two concepts build the basis for the design of an authentication infrastructure.

Ich versichere, dass ich die vorliegende Diplomarbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Joachim Götze

Table of Contents 1 Introduction...3 1.1 Motivation...3 1.2 Objectives...4 1.3 Structure...4 2 Identification and Authentication in a Computer Network...5 2.1 Getting Access to Objects...5 2.2 Multi Sign On...6 2.2.1 Problems with Multi Sign On...7 2.3 Single Sign On...8 2.3.1 What is Single Sign On?...8 2.3.2 Possible Solutions...8 2.3.3 Service based Single Sign On in Detail...13 2.3.4 Problems and Risks...15 2.4 Federation of Trust...15 2.4.1 Models of Federation...16 2.4.2 Pros and Cons of Federation...20 3 Single Sign On with Web Services...22 3.1 What are Web Services?...22 3.1.1 SOAP...23 3.1.2 WSDL...24 3.2 Standards enhancing SOAP...25 3.2.1 WS Security...25 3.2.2 WS Trust...29 3.2.3 WS Federation...37 3.2.4 Security Assertion Markup Language...42 3.2.5 Additional important Standards...47 3.2.6 Applicability...47 4 Model for an Authentication Infrastructure...50 4.1 Single Domain Model...51 4.1.1 Service based Single Sign On...51 4.1.2 Components...52 4.1.3 Communication Flow...53 1

4.1.4 Secure Communication...55 4.1.5 Authorization...63 4.1.6 Delegation...64 4.2 Extended Model for Federated Domains...65 4.2.1 Extension of the Model...65 4.2.2 Federation of Trust...66 4.2.3 Authentication...70 4.2.4 Using a Service...73 4.2.5 Mapping of User Roles...73 4.2.6 Delegation...74 4.3 Conclusion...75 5 Realization of the Model...76 5.1 Basis of the Implementation...76 5.1.1 Java Web Services Developer Pack...76 5.1.2 Java Naming and Directory Interface...77 5.1.3 Java Cryptography Extension...77 5.2 Structure...77 5.2.1 Client...78 5.2.2 Server...78 5.2.3 Service...78 5.2.4 Communication...79 5.2.5 Supporting Classes...79 5.3 Implementation...80 5.3.1 Client...80 5.3.2 Server...81 5.3.3 Service...83 5.4 Possible Improvements...85 6 Summary and Outlook...86 7 Appendix A: Conventions of Notation for Encryption...88 8 Literature...89 2

1 Introduction 1.1 Motivation Web Services are capable of providing all kinds of services to their clients. Although allowing every client to use a Web Service without even knowing anything about the implementation or the location of the Web Service was part of the primary targets, it was soon recognized that this objective leads to several problems. The obvious field of operation is the use of Web Services inside large companies, but often the services are only meant to be used by clients of that company. If a company does not provide internal Web Services only, the security cannot be ensured solely by using a standard corporate firewall controlling the network traffic, because the firewall would not be capable of distinguishing between allowed and prohibited data packets as they are both sent to the same destination: the company's Web Service server. Although there are solutions under development for this (e.g. a Web Service firewall which is able to validate XML [W3C03] data against the WSDL (chapter 3.1.2) specification of a Web Service developed by the Christian Albrechts University in Kiel Communication Systems Research Group [CAU04]), these solutions can only distinguish between proper and improper access, but not between allowed or disallowed clients, especially if the clients are mobile and access the company's network through frequently changing internet access points. Because of these problems several groups started to find a solution that would solve these problems with standards enhancing the current Web Service standards. The target of these standards is not only the security of a single Web Service, but the dynamic interaction of Web Services belonging to different corporations or domains in a secure manner. Additionally the authentication infrastructure is important to enhance the dynamic interaction, because it can simplify the access to resources in the local network and further more provide the capability to access other domains' resources easily. Finding a straightforward way to build an advanced authentication infrastructure that is capable of these abilities and that does not neglect security, could obviously result in improved productivity of the clients and greater safety of the data the companies' assets. 3

1.2 Objectives The primary objectives of this diploma thesis are: A critical overview of the current work of standardization groups to solve the problems stated above, i.e. enhancement of security and providing the ability for authentication and authorization, especially in a federated environment. Development of a model for a distributed single sign on authentication with the ability to utilize a federation of trust on the basis of Web Services and existing authentication infrastructure, e.g. LDAP (Lightweight Directory Access Protocol) server or Unix PAM (Pluggable Authentication Modules). Defining an API (application programming interface) for a single sign on service including delegation of user rights and the ability to map user roles between federated domains. Implementation of a prototype for the single sign on Web Service using Java proving the usability of the model above. 1.3 Structure In order to develop a model for single sign on using federations of trust, in chapter 2 single sign on will be analyzed, specially the characteristics of federations of trust and the problems that may arise because of this authentication strategy. In chapter 3 the recent work of standardization groups to improve the starting point for the development of such a model on the basis of Web Services will be inspected. The development of the model for single sign on authentication will be the central issue of chapter 4, while the focus of chapter 5 will be on the realization and implementation of the model. Finally chapter 6 will present the conclusion and provide information about possible future work. 4

2 Identification and Authentication in a Computer Network One of the main reasons for the use of computer networks is the distribution and access of remote objects. In this context object is an abstraction of e.g. files, printers, emails, etc. Nearly always it is important to protect the objects from illegal use. This problem leads to the identification of users and how they can be authenticated, i.e. proof their identity. The following section will describe what identification and authentication is and give a short overview of possible solutions to reach the goal of protecting objects from not granted access. Later on different authentication infrastructures will be analyzed, especially with the focus on the cooperation of multiple authentication infrastructures. 2.1 Getting Access to Objects Before a person can get access to an object, the person needs to identify himself as a user with the permission to access the object. To understand what identify means, it is important to know what identity is: Identity: The identity of a person are all attributes that define their personality. This not only includes name and address, but also appearance (size, hair color, etc.) and the way other people perceive that person. This means that the identity can change over time. Identification: Identification is a process in which the user presents an attribute that represents his identity. It is common to use a username for identification. After presenting the identifying attribute to the authority granting access to the objects it protects, the authority has to verify the claimed identity. This process is called Authentication. Authentication: Authentication is a process in which the user proves that he is who he claims to be. A usual way to give proof is by presenting a credential, i.e. a shared secret between the authority and the user, e.g. the combination of the username with a password. Only this pair will authenticate the user so he can get the authorization needed to access restricted objects. Now that the user has been authenticated, he can get the right to access any object he is allowed to. 5

Authorization: Authorization gives an identified user the right to access objects depending on his identity. Figure 2.1: Identification Authentication Authorization Figure 2.1 shows the process which results in getting access to an object. In modern operating systems used in a network environment, it is usual to enter username and password only once to get access to all objects the user is allowed to use. There are three terms that are closely related to the authentication process [Cler02]: An authentication infrastructure refers to a set of authentication servers and authentication authorities, providing sourced out authentication services. Authentication servers are the physical machines performing the authentication functions. Authentication authorities are a logical trust related concept: they are the entities that are trusted by users to perform reliable authentication functions. Every authentication authority controls a set of objects (resources) located on machines that are part of the network controlled by the authentication authority. This part of a network is often called a domain or realm. The authentication server assuring that a user s identity is authentic is called domain controller. If the user enters another domain, he needs to re authenticate in the new domain. If the number and diversity of domains the user has to interact with grows, this will lead to more and more different credentials and different ways to authenticate, e.g. public key environments. Because of the need to provide credentials several times, this is called multi sign on. 2.2 Multi Sign On Analyzing multi sign on environments results in several problems that all have their source in the use of multiple authentication authorities. As Figure 2.2 shows, there is no connection between different authentication authorities, which implicates multiple and because of the technology in use maybe diverse credentials. 6

The following section will outline some of the problems in such an environment and why they are connected to multi sign on. Figure 2.2: Multi Sign On 2.2.1 Problems with Multi Sign On First, there is the time lost, because of performing log on tasks over and over again. Jan de Clercq states in [Cler02]: A study conducted by the Network Applications Consortium in large enterprises showed that users spend an average of up to 44 hours per year to perform log on tasks to access a set of 4 applications.. Second, there is the time spent by the helpdesk to reset passwords. The study mentioned above stated that companies helpdesks spend 70 per cent of their calls with password reset requests [Cler02]. The third problem is diminished security when web browsers store passwords for the user or users who write down their passwords in order to prevent forgetting it. Sometimes these notes even end up on the backside of keyboards or pinned to the screen where they are accessible to everybody who passes by. The difficulty in increasing security in such a heterogeneous authentication infrastructure is the forth problem. An investment to increase the security of the whole environment is either very expensive (because of the amount of applications that need to be changed) or it does only improve a small amount of applications, e.g. the proprietary log on scheme of an application cannot be improved, because of a missing interface to extend the functionality. 7

These problems are closely related to multi sign on environments. Because of the diversity, the disadvantages of multiple authentication infrastructures (e.g. loss of user productivity or lack of security), are difficult to measure. Nevertheless the importance of security is pointed out in a study from the Center for Research on Information Systems at the University of Texas which shows that 90 percent of all companies that suffer a complete loss of data go into bankruptcy [Fuji04]. Obviously the reduction of multiple authentication authorities to only one, where the user has to sign on, cannot solve all security problems, but concentrating log on to one independent authentication authority can greatly improve security and decrease the amount of future investments in security improvements. 2.3 Single Sign On The reduction of multiple authentication authorities to only one, where the user has to sign on, includes the outsourcing of authentication processes to a specialized infrastructure that does not only handle authentication for several applications but for all applications. Such an environment of authentication authorities is called a single signon (SSO) environment. 2.3.1 What is Single Sign On? The Open Group defines single sign on as follows: Single sign on is a mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the necessity to enter multiple passwords. [TheO99] In order to stick to the former defined terminology of authentication authorities single sign on can be defined as follows: Single sign on is the ability for a user to authenticate once to a single authentication authority and then access other protected resources without re authentication. [Cler02] 2.3.2 Possible Solutions Although the definition of SSO is quite simple, it is not easy to achieve. There are three primary approaches to get SSO: client based, server based and service based. In the following, the differences between these approaches will be explained in detail as well as the advantages and limitations they bring along [Andr04]. 8

Client based SSO: A client based solution (sometimes called Secure Client Side Credential Caching) is a password management tool storing all authentication information the user has to remember and providing it every time it is needed. If the credentials are valid the user will be logged on transparently to the other resource servers. Figure 2.3: Client based SSO In the context of this architecture it is absolutely vital to store the cached credentials securely, because the credentials may be used to access business critical applications or data. In this case it is not recommended to use this approach on portable client devices or on operating system platforms having a bad security reputation. If the primary credentials unlocking the client side cache are local credentials local meaning: defined in the local machine s security database and only valid for accessing local machine resources the secure client side credential cache can be implemented without the use of a real authentication infrastructure. To improve security it is helpful to combine the access to the client side cache with the access to the primary domain, so that the credentials are not local credentials, but domain credentials. Server based SSO: In a server based solution all passwords are stored in a central repository on a server that provides the needed information directly to the application asking for them. This approach is also called Secure Server Side Credential Caching. 9

In a secure server side credential caching architecture the primary credential database contains (besides the user s primary credentials) the mappings between a user s primary and secondary credentials. The secondary credential database keeps a copy of the secondary credentials, too. It is important in this approach to keep the copies of the secondary credentials and the mappings in the primary and the secondary credential database synchronized. Figure 2.4: Server based SSO Depending on the strategy to synchronize the credentials it can be necessary to have a trust relationship between the secondary authentication authorities and the primary authentication authority. There are three main synchronization approaches: The primary credential database includes the synchronization services. An external software handles the credential synchronization. Administrators or users (self administration) perform the synchronization. Obviously the first and the second approach need a trust relationship between the authentication authorities, while the last approach does not. Service based SSO: Management of authentication information can also be provided as a service. This is done by a standardized scheme to handle authentication that is located on a centralized authentication infrastructure. From the user s point of view one authentication gives transparent access to all services that use this single sign on service. 10

Figure 2.5: Service based SSO Now that the three approaches to SSO have been clearly defined, an analysis of their advantages and disadvantages can be made: 11

SSO approach Clientbased Serverbased Servicebased Advantage Easy to set up No modification of the applications is needed Enables the system administrator to check password strength and monitor security issues Authentication is possible from any workstation that has access to the server No user interaction is needed when a new application is added to the environment Transparent to user No user interaction is needed when a new application is added to the environment Single point of authentication improvements Authentication is possible from any workstation that has access to the service Disadvantage Table 2.1: Advantages and Disadvantages of SSO Approaches Every time a new application or site is added it requires some interaction with the user Lack of industry standardization in password specifications Little flexibility, because the user will have problems if he is not working at his usual desk Lack of industry standardization in password specifications Need for a highly available server hosting the service Need for a highly available server hosting the service Possibility of creating a user interaction profile (user's privacy could be weakened) A comparison of the different approaches with the definition of single sign on is important to point out the differences between the approaches. Comparing the definition of client based SSO with the definition of SSO itself, it is obvious that client based SSO is not a clean approach to single sign on. There is not only one authentication authority, there is also no reduction of authentication authorities at which the user has to sign on. Client based SSO only hides the problems of multi sign on and helps the user to remember his credentials. 12

Neither is server based SSO a pure approach to SSO. The user only needs to log on to the server once, but it expands the number of authentication authorities by the new server that stores and protects the credentials. Still there are many authentication authorities at which the user has to sign on, they are only hidden to the user. The only real approach to single sign on is the service based approach. The amount of authentication authorities at which the user has to sign on is reduced to only one and only one log on is needed to get access to the whole domain and every domain including an authentication authority trusting the primary authentication authority. 2.3.3 Service based Single Sign On in Detail There are two flavors of service based single sign on: token based SSO and an architecture based on a public key infrastructure (PKI). Both authentication architectures use only a single set of credentials which is recognized by many different authentication authorities. A major advantage of these approaches is the rather homogeneous environment. Homogeneous in this context means: using a single account naming format and authentication protocol that are supported by every entity, application and service participating in the SSO architecture. Figure 2.6: Token based SSO In a token based SSO environment (illustrated in figure 2.6) the user receives a temporary token after his primary sign on. This token has to be used to proof authenticity to every service he wants to use. A trust relationship between the secondary authentication authorities and the primary authentication authority enables the user to 13

utilize services secured by a secondary authentication infrastructure with the temporary token from the primary authentication authority without a re authentication. A typical example for this authentication strategy is the Kerberos authentication protocol [Opp96]. Figure 2.7: PKI based SSO In a PKI based SSO architecture users first register themselves at a trusted authentication authority (in this case called: certification authority, CA) or at one of the authentication authority s registration agents (called registration authority, RA). During this registration process several things occur: users identify themselves using a set of credentials; an asymmetric key pair is generated by the client side; the public key of this key pair is offered to the CA (or RA) for certification. The CA (or RA) will verify the user s credentials and the public key. A public key certificate will be generated if the credentials are valid. This certificate will be sent back to the user and stored together with the user s private key on the user s machine. In a subsequent authentication request a token will be generated out of the user s private key and the public key certificate to proof the user s identity. Because of a trust relationship any secondary authentication authority will accept such a token. This trust relationship is represented by a secondary authentication authority s certificate issued by the primary authentication authority. 14

2.3.4 Problems and Risks The detailed view on service based single sign on pointed out, that both approaches are not compatible. Especially in a grown environment it will be necessary to find a solution of how to combine both single sign on domains (PKI based and token based). This solution could be a federation of trust which will be under thorough investigation in the next section. A major problem of single sign on is the Key to the Kingdom problem. As the previous sections showed, there is no need for many credentials in a single sign on environment. The Key to the Kingdom problem is a synonym for the problem that will arise if the main credential is compromised. This results in the exposure of the whole single sign on environment and all data and resources that are protected by the authentication infrastructure. The same applies to a security breach by poorly developed software in the authentication service (e.g. buffer overflow) which enables an intruder to get authenticated falsely without the use of credentials. Although the single sign on environment could mean higher risk of an attack to intrude the environment, the single sign on environment itself leads to a solution for that. Because of having only one major authentication authority, the overall security standard of the whole environment is dependent mostly on the security standard of the authentication authority. If the security level of the authentication authority can be improved, it will improve the security for the whole environment. As there is only one point of improvement, the cost of improvement is reduced in contrast to a multiple sign on solution having many points of improvement. 2.4 Federation of Trust Because of the diversity of single sign on solutions, it is difficult to combine several infrastructures to enhance the range of a single sign on domain. Especially if two companies are working together closely, the ability of single sign on is highly desirable, but none of the companies would be willing to change their complete authentication infrastructure to match with the infrastructure of the other company. Additionally it is not the same kind of trust relationship as it is between two authentication authorities inside a single company. Both companies would only be willing to give access to information needed for their joint venture, but not to all business secrets, and they want complete control of the access rights they are granting. 15

Another problem arises from short term co operations. The trust relationship has to be installed quickly and it may not exist for a long time. A Federation of Trust between two authentication authorities can solve these problems by defining mechanisms to enable different security realms to federate using different or alike mechanisms by allowing and brokering trust of identities, attributes, authentication between participating authentication authorities. 2.4.1 Models of Federation [IBM03b] defines the following different models of federation on the basis of these two important terms: A security token service (STS) is a service that issues security tokens. That is, it makes assertions based on evidence that it trusts, to whoever trusts it. To communicate trust, a service requires proof, such as a security token or set of security tokens, and issues a security token with its own trust statement. This forms the basis of trust brokering. An identity provider (IP) is an entity that acts as an authentication service to end requestors and as a data origin authentication service to service providers (this is typically an extension of a security token service) and can make identity claims in issued security tokens. Additionally the acronym IP/STS is used to indicate a service that is either an identity provider (IP) or security token service (STS). Figure 2.8 shows the basic process to access a resource in a federated environment. Starting point are the two IP/STS which have a trust relationship to each other. The requestor collects a security token at the local IP/STS that is valid for the resource the requestor wants to use (1). In order to obtain an access token the requestor proves his identity to the IP/STS controlling the resource s domain (2). Now the requestor gets access to the resource by presenting the access token to the resource (3). The trust relationship between the IP/STS allows the resource s IP/STS to validate the security token the requestor gets in his local domain and to issue an access token for the resource s domain. 16

Figure 2.8: Basic Security Token Service Figure 2.9: Alternative Security Token Service The alternative scenario (figure 2.9) is a slightly different approach. The requestor receives a security token from the local IP/STS (1). This token is presented to the resource the requestor wants to access (2). In order to grant the wanted access, the resource validates the presented token at its local IP/STS (3). Because of the trust 17

relationship between the IP/STS the security token of the requestor s domain could be validated from the resource s IP/STS. Enhancing the basic trust relationship there can be an indirect trust relationship (figure 2.10). The IP/STS that has to validate the requestor s identity must use a trusted intermediate IP/STS which itself trusts the requestor s IP/STS issuing the security token for the requestor. This indirect trust relationship is not only limited to a single intermediary IP/STS. On the contrary there can be many IP/STS between the requestor's IP/STS and the service's IP/STS. Additionally a trust network must not be linear, it can be much more diverse and complex. Even cycles within the network graph are possible. Figure 2.10: Indirect Trust In practice, a requestor is able to interact with multiple resources/services which are part of multiple trust realms as illustrated in figure 2.11. The figure shows that the requestor obtains a security token from his local IP/STS (1). In order to access multiple resources, he obtains several access tokens from IP/STS of different domains (2/4). The requestor 18

presents these access tokens to the corresponding resources (3/5). The number of domain borders that need to be crossed to access the needed resources is not limited. Figure 2.11: Multiple Trust Domains Figure 2.12: Delegation An additional enhancement of trust relationships is delegation. Figure 2.12 shows that the requestor after obtaining a security token (1) requests an access token for the desired resource (2). Then the requestor gets access to a resource in another domain (3). 19

This resource needs to access another resource from a third trust realm on behalf of the requestor to fulfill its task (5), obtaining an access token by presenting the identity of the initial requestor and indicating proof of delegation (4). It is important to note that there are numerous variations of this scenario. Figure 2.13 shows that the IP/STS for the final resource only has a trust relationship with the IP/STS from the original requestor, as opposed to the scenario in figure 2.12 where no trust relationship connects the original requestor's IP/STS and the IP/STS of the final resource. Although delegation can be a valuable tool that can be very useful for granting shortterm access rights without the need to contact a network administrator (who must not forget to cancel the access rights, if they are not needed anymore), it is very important to mention that an IP/STS must not allow delegation without being specifically authorized by the original requestor. Figure 2.13: Advanced Delegation 2.4.2 Pros and Cons of Federation The main advantage of a federated single sign on environment is the extension of single sign on beyond the scope of the primary authentication authority of the home domain. 20

A federation of trust allows the user to utilize not only services in his home domain, it allows the user to utilize services in foreign domains without having credentials for them. This advantage also leads to the main disadvantage. A federation of trust does not only extend the favorable use of credentials, it additionally extends the Key to the Kingdom problem of single sign on. Now an intruder does not only have the ability to penetrate a domain through a security issue, but he now has the ability to penetrate a domain through a security issue in a federated environment. This problem points out that the trust that is needed for building a federation of trust not only includes trust in the way the partners of the co operation use the data and services provided, it also includes trust in the security provided by others. A lack of security in one domain may give an intruder access to many highly protected domains and compromises their services which would be more secure without the federation of trust. A solution for a federated single sign on service must not only benefit from the federation of trust, it also has to give security aspects and security risks introduced by a federation of trust a closer look. 21

3 Single Sign On with Web Services Existing solutions for operating systems and websites do not have the ability to become a combined solution for any environment that could benefit from single sign on. For example a solution for single sign on within a certain group of websites does only offer that service for this small group and can only interact with other single sign on domains after a lot of work integrating the new domains. Even if that problem could be solved, it is usually not possible to extend the single sign on service apart from websites. Web Services are independent from programming languages, operating system environments, etc. and can provide a service oriented architecture (SOA) that allows the use of single sign on in every environment. 3.1 What are Web Services? The World Wide Web Consortium defines Web Services as follows: A Web Service is a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine processable format (specifically WSDL). Other systems interact with the Web Service in a manner prescribed by it's description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web related standards. [W3C04] Comparing the previous definition with the following (older) definition shows that a lot of development not only to improve the standard but also to improve the understanding of Web Services has been done: A Web Service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web Service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols. [W3C02] It is obvious that of now (2004), according to the World Wide Web Consortium SOAP and WSDL are important and required standards to use Web Services, while the older definition (2002) only states that the public interfaces and bindings are somehow described using XML. For a more thorough understanding of Web Services, it is necessary to have a closer look at SOAP and WSDL. 22

3.1.1 SOAP SOAP (former an abbreviation for Simple Object Access Protocol, now a term on its own) defines a communication standard between services using for example the Hypertext Transfer Protocol (HTTP) [IETF99] to carry Remote Procedure Calls (RPC) and their results. SOAP messages are based on the extensible Markup Language (XML) [W3C03]. This allows SOAP to transfer information between services in a decentralized and distributed environment. Because of the objective to make SOAP as flexible as possible, some of the basic transport protocols are Hypertext Transfer Protocol, File Transfer Protocol [IETF85] or Simple Mail Transport Protocol [IETF01], but other transport protocols are possible, too. Figure 3.1: Components of a SOAP Message A SOAP message has to have two components which can be extended by two optional components (figure 3.1): SOAP envelope: This is the container for the whole information (based on XML). The envelope contains two elements: the SOAP header and the SOAP body. SOAP header (optional): The header contains information apart from the actual function call, e.g. information which SOAP intermediary this message should pass before reaching the destination. 23

SOAP body: The body contains the data described by XML. There are three different types of SOAP messages: a request, a response and a fault (which sends detailed information about the error that has occurred). SOAP attachment part (optional): As the SOAP body can only transport data coded in XML, there is another solution needed to transfer complete files or non XML data. A message containing such attachments is called SOAP message package and uses MIME (Multipurpose Internet Mail Extensions [IETF96]) to extend the message by additional body parts that can contain differently coded data. For a more detailed introduction refer to [W3C03a]. 3.1.2 WSDL The World Wide Web Consortium describes the Web Services Description Language WSDL as follows: WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document oriented or procedureoriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate [W3C01]. The main goal for the development of WSDL is to define a language to describe the service offered so that it is usable for a computer. To achieve that goal, a WSDLdocument uses the following elements in the definition of network services: Types: A container for data type definitions. Messages: An abstract definition of communicated data. Operation: Description of a supported action. Port Type: A set of operations supported by an endpoint. Binding: Specification of the protocol and data format for a particular port type. This leads to several advantages that result in the usage of WSDL: The formal definition leads to definite semantics of the WSDL document. 24

The WSDL document can be used to generate the code skeleton of a Web Service to ease the problems of implementation for the service provider and the service user. The dynamic detection and usage of Web Services is improved by the formal definition that is usable for a computer. For a more detailed introduction refer to [Boo03]. 3.2 Standards enhancing SOAP The development of a federated single sign on environment depending on Web Services is supported by several enhancements to SOAP. The most important enhancements for single sign on provide e.g. message protection (WS Security), management of trust relationships (WS Trust), federated authentication and authorization across different trust realms (WS Federation). In the following, because of their importance, these enhancements will be explained in greater detail. 3.2.1 WS Security The main purpose of the specification of Web Services Security (WS Security) is the enhancement of SOAP to provide protection through message integrity, message confidentiality, and single message authentication. Additionally, WS Security provides a general purpose mechanism for associating security tokens with messages, which is not focused on any specific type of security token. Because of this flexibility the extension can be used as a basis for the construction of a wide variety of security models including PKI and Kerberos [Opp96]. A more detailed description of WS Security is provided by [IBM02]. Three main mechanisms are defined in the specification of WS Security to reach the goals described above: security token propagation, message integrity, and message confidentiality. To embed these mechanisms in a SOAP message a new header block had to be defined. The <Security> header block (figure 3.2) allows the attachment of security related information targeted at a specific receiver. This may either be the ultimate receiver of the message or an intermediary. Because of that, there can be more then one <Security> header block in a SOAP message. A SOAP intermediary can add new sub elements to an existing <Security> header block, if they are targeted to the same SOAP node. If 25

there is no existing <Security> header block for a target, a SOAP intermediary can add <Security> header blocks. To distinguish several <Security> header blocks, i.e. several recipients, the S:actor attribute has to be defined. There can never be a second <Security> header block with the same S:actor attribute and there can be only one with an empty S:actor attribute. A <Security> header block with an empty S:actor attribute can be consumed by any SOAP node, but must not be removed prior to reaching the final destination of the SOAP message. If a SOAP node adds elements to a <Security> header block, these elements should be prepended to the existing elements. This prepending rule ensures that the receiver application may process sub elements in the order they appear, because there will be no forward dependency among the sub elements. <S:Envelope> <S:Header> <Security S:actor= S:mustUnderstand= > </Security> </S:Header> </S:Envelope> Figure 3.2: Security Header Block 3.2.1.1 Security Token Propagation Four elements are needed to embed or to reference security tokens in SOAP messages: UsernameToken, BinarySecurityToken, SecurityTokenReference and ds:keyinfo. The <UsernameToken> element (figure 3.3) is a way of providing a username and optional password information for basic authentication. 26

<UsernameToken Id= > <Username> </Username> <Password Type= > </Password> </UsernameToken> Figure 3.3: UsernameToken Element or Attribute /UsernameToken /UsernameToken/@Id /UsernameToken /Username /UsernameToken /Password /UsernameToken /Password/@Type Description Element for sending basic authentication information. A string label for this security token. This required sub element specifies the username of the authenticating party. This optional sub element provides password information. This optional attribute specifies the type of password being provided. There are two predefined types: wsse:passwordtext The actual password for the username, wsse:passworddigest The digest of the password for the username. The value is a base64 encoded SHA1 hash value of the UTF8 encoded password. Table 3.1: UsernameToken The <BinarySecurityToken> element (figure 3.4) is used for the propagation of tokens in binary or other non XML formats. <BinarySecurityToken Id= EncodingType= ValueType= /> Figure 3.4: BinarySecurityToken 27

Element or Attribute /BinarySecurityToken /BinarySecurityToken/@Id /BinarySecurityToken /@ValueType /BinarySecurityToken /@EncodingType Description Element to include a binary encoded security token. An optional string label for this security token. The ValueType attribute allows a qualified name that defines the value type and space of the encoded binary data. There are three predefined types: wsse:x509v3 x.509 v3 certificate, wsse:kerberosv5tgt Kerberos v5 ticket granting ticket, wsse:kerberosv5st Kerberos v5 service ticket. The EncodingType attribute is used to indicate the encoding format of the binary data. The following encoding formats are predefined: wsse:base64binary XML Schema base 64 encoding, wsse:hexbinary XML Schema hex encoding. Table 3.2: BinarySecurityToken The <SecurityTokenReference> element provides a mechanism to reference security tokens that reside somewhere else and need to be pulled by the receiving application. <SecurityTokenReference Id= > <Reference URI= /> </SecurityTokenReference> Figure 3.5: SecurityTokenReference Element or Attribute Description /SecurityTokenReference Element to provide a reference to a security token. /SecurityTokenReference/@Id An optional string label for this security token reference. /SecurityTokenReference This sub element is used to identify a location for a /Reference security token. /SecurityTokenReference This attribute specifies a URI for where to find a /Reference/@URI security token. Table 3.3: SecurityTokenReference The <ds:keyinfo> element (defined in the XML Signature specification, refer to chapter 3.2.5.1) can be used for carrying key information. It is allowed for different key types and for future extensibility. 28

3.2.1.2 Message Integrity The <Security> header block can be extended by the sub element <ds:signature> (defined in the XML Signature specification, refer to chapter 3.2.5.1) to enable message receivers to determine whether a message was altered during transit and to verify that a message was sent by the possessor of a particular security token. The specification of this sub element allows for multiple signatures to be attached to a message, each referencing different, even overlapping, parts of the message. The WS Security specification builds on XML Signature [W3C02a] and therefore has the same requirements for algorithms. 3.2.1.3 Message Confidentiality In order to protect a message from being intercepted, the WS Security specification allows encryption of any combination of header blocks, body blocks, any of their substructures and attachments by either a symmetric key shared by the sender and the receiver or a key carried in the message in encrypted form. Again, as with message integrity, message confidentiality in the WS Security specification builds on another specification XML Encryption [W3C02b]. 3.2.2 WS Trust WS Security defines basic mechanisms for SOAP messages to provide secure messaging. The specification of the Web Services Trust Language (WS Trust) defines an extension built on WS Security to request and issue security tokens and to manage trust relationships. A more detailed description of WS Trust is provided by [IBM02a]. 3.2.2.1 Security Token Issuance, Validation and Exchange In the following section the requesting and returning of security tokens, scope, key and encryption requirements of security tokens, and the delegation and forwarding of security tokens as defined by the specification WS Trust will be explained. All these elements have to be placed inside the body of a SOAP message. 29

The <RequestSecurityToken> element (figure 3.6) is used to request a security token. This element should be signed by the requesting party. If the element is signed, the requestor must prove any claim to the satisfaction of the security token service. <RequestSecurityToken> <TokenType>...</TokenType> <RequestType>...</RequestType> <Base>...</Base> <Supporting>...</Supporting> </RequestSecurityToken> Figure 3.6: RequestSecurityToken Element or Attribute /RequestSecurityToken /RequestSecurityToken /TokenType /RequestSecurityToken /RequestType /RequestSecurityToken /Base /RequestSecurityToken /Supporting Description Element to request the issuance of a security token. This optional sub element describes the type of the security token requested. This sub element is used to indicate the action that is being requested. There are three predefined types: wsse:reqissue Issue security token, wsse:reqvalidate Validate security token, wsse:reqexchange Exchange security token. This optional sub element has the same type as the <SecurityTokenReference> element defined in WS Security and references the primary (base) tokens used to validate the authenticity of a request. This element is provided if the supporting token, e.g. <UsernameToken>, cannot provide a signature or if the existing signatures do not all support the authorization. This optional sub element has the same type as the <SecurityTokenReference> element defined in WS Security referencing the supporting tokens that are used to authorize this request. It is an aid to the recipient service and is used to identify tokens in a certificate authority. Table 3.4: RequestSecurityToken Additionally WS Trust defines some extensions to the <RequestSecurityToken> element (figure 3.7) for scope requirements on the security token returned. 30

<RequestSecurityToken> <wsp:appliesto>...</wsp:appliesto> <Claims>...</Claims> </RequestSecurityToken> Figure 3.7: RequestSecurityToken (Scope Requirements) Element or Attribute /RequestSecurityToken /wsp:appliesto /RequestSecurityToken /Claims Description This optional sub element specifies the scope for which this security token is desired. This optional sub element specifies a set of claims. Mostly these claims are required by a service s policy. Table 3.5: RequestSecurityToken (Scope Requirements) Although the sub elements <wsp:appliesto> and <TokenType> are optional, it is required that at least one of them is returned. If both are returned, the <wsp:appliesto> element takes precedence. In some situation it is useful to express key and encryption requirements. WS Trust defines extensions to the <RequestSecurityToken> element (figure 3.8) for requesting specific types of keys or algorithms or both. <RequestSecurityToken> <RequestKeyType>...</RequestKeyType> <RequestKeySize>...</RequestKeySize> <RequestSignatureAlgorithm>...</RequestSignatureAlgorithm> <RequestEncryption>...</RequestEncryption> <RequestProofEncryption>...</RequestProofEncryption> <UsePublicKey Sig=... > <ds:keyinfo>...</ds:keyinfo> </UsePublicKey> <UseKeyRef Sig=... >...</UseKeyRef> </RequestSecurityToken> Figure 3.8: RequestSecurityToken (Encryption Requirements) 31

Element or Attribute /RequestSecurityToken /RequestKeyType /RequestSecurityToken /RequestKeySize /RequestSecurityToken /RequestSignatureAlgorithm /RequestSecurityToken /RequestEncryption /RequestSecurityToken /RequestProofEncryption /RequestSecurityToken /UsePublicKey /RequestSecurityToken /UsePublicKey/@Sig /RequestSecurityToken /UseKeyRef /RequestSecurityToken /UseKeyRef/@Sig Description This optional sub element indicates the type of key desired in a security token. The predefined values are wsse:publickey and wsse:symmetrickey. This optional sub element specifies the size of the key required. The semantics of the value are depending on the KeyType. Because of this being a request, the requested security token is not obligated to use the requested key size. The information is provided as an indication of the desired strength of security. This optional sub element indicates the desired signature algorithm for the returned security token. This optional sub element indicates that the requestor desires any returned secrets in the issued security token to be encrypted. This optional sub element indicates that the requestor desires any returned secrets in the issued proof ofpossession token to be encrypted. This optional element indicates that the requestor s public key should be used in the security token. This optional attribute specifies the Id of the corresponding signature to be used. The contents of this optional element references the security token containing the key which should be used in the requested security token. This optional attribute specifies the ID of the corresponding signature to be used. Table 3.6: RequestSecurityToken (Encryption Requirements) In order to support the delegation and forwarding of security tokens, WS Trust specifies another extension to the <RequestSecurityToken> element (figure 3.9). 32

<RequestSecurityToken> <OnBehalfOf>...</OnBehalfOf> <DelegateTo>...</DelegateTo> <Forwardable/> <Delegatable/> <Proxiable/> </RequestSecurityToken> Figure 3.9: RequestSecurityToken (Delegation and Forwarding) Element or Attribute /RequestSecurityToken /OnBehalfOf /RequestSecurityToken /DelegateTo /RequestSecurityToken /Forwardable /RequestSecurityToken /Delegatable /RequestSecurityToken /Proxiable Description This optional sub element indicates that the requestor is making the request on behalf of another. The identity on whose behalf the request is being made is specified by placing a security token or <SecurityTokenReference> element within this element. This sub element is optional and indicates that the requested or issued token can be delegated to another identity. The identity receiving the delegation is specified by placing a security token or <SecurityTokenReference> element within this element. This optional sub element is to request a security token to be marked as forwardable. This is used to mark a returned token so that it can be used to obtain a token for another party. This optional sub element is to request a security token to be marked as delegatable. This allows to mark a returned token so that it can be delegated to another party. This optional sub element is to request a security token to be marked as proxiable. This is used to mark a returned security token so that it can be forwarded and used by another party then originally destined. Table 3.7: RequestSecurityToken (Delegation and Forwarding) Finally WS Trust defines an extension to the <RequestSecurityToken> element (figure 3.10) so that token lifetime and renewal requirements on the requested token can be specified. 33

<RequestSecurityToken> <AllowPostdating/> <Renewing Allow=... OK=... /> <Lifetime> <wsu:created>...</wsu:created> <wsu:expires>...</wsu:expires> </Lifetime> </RequestSecurityToken> Figure 3.10: RequestSecurityToken (Token Lifetime) Element or Attribute /RequestSecurityToken /AllowPostdating /RequestSecurityToken /Renewing /RequestSecurityToken /Renewing/@Allow /RequestSecurityToken /Renewing/@OK /RequestSecurityToken /Lifetime /RequestSecurityToken /Lifetime/@wsu:Created /RequestSecurityToken /Lifetime/@wsu:Expires Description This sub element indicates that the returned token should allow requests for postdated tokens. This optional sub element is used to specify renew semantics for types that support this operation. This optional Boolean attribute is used to request a renewable token. This optional Boolean attribute is used to indicate that a renewable token is acceptable if the requested duration exceeds the limit of the issuance service. This optional sub element is used to specify the desired valid time range for the returned security token. This optional attribute specifies an absolute time representing initial validity time for the token. If this time occurs in the future then this is a request for a postdated token. If this attribute is not specified, then the current time is used as an initial period. This optional attribute specifies an absolute time representing the upper bound on the validity time period of the requested token. If this attribute is not specified, then the services will choose the lifetime of the security token. Table 3.8: RequestSecurityToken (Token Lifetime) The <RequestSecurityTokenResponse> element (figure 3.11) is used to return a security token. 34

<RequestSecurityTokenResponse> <TokenType>...</TokenType> <KeyType>...</KeyType> <KeySize>...</KeySize> <wsp:appliesto>...</wsp:appliesto> <RequestedSecurityToken>...</RequestedSecurityToken> <RequestedProofToken>...</RequestedProofToken> </RequestSecurityTokenResponse> Figure 3.11: RequestSecurityTokenResponse Element or Attribute /RequestSecurityTokenResponse /RequestSecurityTokenResponse /TokenType /RequestSecurityTokenResponse /KeyType /RequestSecurityTokenResponse /KeySize /RequestSecurityTokenResponse /wsp:appliesto /RequestSecurityTokenResponse /RequestedSecurityToken /RequestSecurityTokenResponse /RequestedProofToken Description Element to respond to a security token request. This optional sub element describes the type of the security token requested. This optional sub element specifies the type of key used in the token. This optional sub element indicates the size of the key returned. This optional sub element specifies the scope to which this security token applies. This optional sub element is used to return the requested security token. Instead of a security token, a security token reference may be used. This optional sub element is used to return the proof of possession token associated with the requested security token. Instead of a proof ofpossession token, a security token reference may be used. Table 3.9: RequestSecurityTokenResponse The sub elements <RequestedSecurityToken>, <RequestedProofToken> and <wsp:appliesto>, <TokenType> are optional, but it is required that at least one of them is returned unless there is an error. The elements <RequestSecurityToken> and <RequestSecurityTokenResponse> provide all the mechanism needed to handle security tokens, but it may be necessary to request additional confirmation from either the requestor or the issuer. This process is called challenging. WS Trust defines four sub elements to handle such a challenge: <SignChallenge>, <SignChallengeResponse>, <SecurityTokenReference>, <BinaryNegotiation> (figure 3.12). These elements can either be used in a 35

<RequestSecurityToken> or in a <RequestSecurityTokenResponse> (this is indicated by the... in table 3.10). <SignChallenge> <Challenge>...</ Challenge> <SecurityTokenReference>...</SecurityTokenReference> </SignChallenge> <SignChallengeResponse> <SecurityTokenReference>...</SecurityTokenReference> <ds:signature>...</ds:signature> </SignChallengeResponse> <SecurityTokenReference>... </SecurityTokenReference> <BinaryNegotiation ValueType="..." EncodingType= >... </BinaryNegotiation> Figure 3.12: Challenging Element or Attribute /SignChallenge /SignChallenge /Challenge /SignChallenge /SecurityTokenReference /SignChallengeResponse /SignChallengeResponse /ds:signature /SignChallengeResponse /SecurityTokenReference Description This optional sub element specifies a challenge that requires the other party to sign a specific set of information. This required sub element specifies what parts of the challenge must be signed as part of a valid response. This optional sub element is used to reference security tokens passed as part of the negotiation process. This optional sub element describes a challenge response. This optional sub element is the XML Signature element for attaching a signature. This optional sub element is used to reference security tokens passed as part of the negotiation process. 36

Element or Attribute /SecurityTokenReference /BinaryNegotiation /BinaryNegotiation /@ValueType /BinaryNegotiation /@EncodingType Description This optional sub element is used to reference security tokens passed as part of the negotiation process. This optional sub element is used for a security negotiation that involves the exchange of binary data as part of an existing negotiation protocol. The data is encoded in Base64. This required attribute specifies a qualified name to identify the type of negotiation and the value space of the binary data. This required attribute specifies a qualified name to identify the encoding format if different from Base64. Table 3.10: Challenging 3.2.2.2 Managing Trust Relationships WS Trust defines two types of models for trust: in band and out of band. In band means that the assessment of trust is based on information in the message flow (security token exchange) while out of band means that an administrator defines all tokens of a certain kind as trusted (trust axiom). The management of trust relationships is based on the organization of trust roots. Fixed trust roots is the simplest mechanism. The environment has a fixed set of trust roots. Any request will be evaluated to determine if it contains security tokens from one of the trusted roots. Trust hierarchies built on the fixed trust roots mechanism. A service may choose to allow hierarchies of trust as long as the trust chain eventually leads to one of the known trust roots. Authentication services are another approach to trust relationships. This can essentially be thought of as a fixed trust root where the user only trusts the authentication service. The user forwards tokens to the authentication service which replies with an authoritative statement attesting to the authentication. 3.2.3 WS Federation The Web Services Federation Language (WS Federation) extends the specification of Web Services on the basis of WS Security and WS Trust. The main focus of WS 37

Federation is authentication and authorization in federations across different trust realms. In addition the foundations for pseudonym and attribute services are built. For a more detailed information about WS Federation including pseudonym and attribute services refer to [IBM03b]. WS Federation describes several models for authentication and authorization in federated environments which are similar to the models described in chapter 2.4. Moreover an extension is specified of an element to sign out from a single sign on environment. 3.2.3.1 Single Sign Out The <wsse:signout> element (figure 3.13) is used to indicate a security token service that the requestor is initiating a termination of the actual single sign on session. The security token service can then safely erase any cached data about the requestor. <wsse:signout wsu:id="..."> <wsse:realm>...</wsse:realm> <wsse:signoutbasis>...</wsse:signoutbasis> </wsse:signout> Figure 3.13: Single Sign Out Element or Attribute /SignOut /SignOut/Realm /SignOut/SignOutBasis /SignOut/@wsu:Id Description This element represents a sign out message. This optional sub element specifies the realm from which the requestor wants to sign out. This sub element contents an information that indicates which requestor wants to sign out. Therefore the <UsernameToken> is the most common content. This optional attribute specifies a string label for this element. Table 3.11: Single Sign Out Sometimes it may be necessary that an indicated sign out needs to be distributed across the federation. In order to request such messages or to cancel the request the elements <RequestSSOMessage> (figure 3.14) and <CancelSSOMessage> (figure 3.15) can be used. 38

<wsse:requestssomessages> <wsa:endpointreference>...</wsa:endpointreference> <wsse:realm>...</wsse:realm>...security tokens... </wsse:requestssomessages> Figure 3.14: RequestSSOMessages Element or Attribute /RequestSSOMessages /RequestSSOMessages /wsa:endpointreference /RequestSSOMessages /Realm /RequestSSOMessages / security tokens Description This element is used to request federated sign out messages. This required sub element indicates the endpoint to which the messages are to be sent. This optional sub element indicates to which realm the sign out applies. The contents of these optional sub elements indicates to which identities these messages are restricted. The most common token here is the <UsernameToken>. Table 3.12: RequestSSOMessages <wsse:cancelssomessages> <wsa:endpointreference>...</wsa:endpointreference> <wsse:realm>...</wsse:realm>...security tokens... </wsse:cancelssomessages> Figure 3.15: CancelSSOMessages Element or Attribute /CancelSSOMessages /CancelSSOMessages /wsa:endpointreference /CancelSSOMessages /Realm /CancelSSOMessages / security tokens Description This element is used to cancel federated Single Sign On messages. This required sub element indicates the endpoint to which the messages are to be sent. This optional sub element indicates to which realm the sign out applies. The contents of these optional sub elements indicates to which identities these messages are restricted. The most common token here is the <UsernameToken>. Table 3.13: CancelSSOMessages 39

3.2.3.2 Active Requestor Profile Because of the WS Federation specification concentrates on models how a federated environment could be build, there are two profiles defined to specify the use of the WS Federation specification. The first is the Active Requestor Profile [IBM03]. This profile defines how the federation model is applied to active requestors such as SOAP applications. Figure 3.16: Signing on and using a service This profile was defined to characterize specific message exchange patterns. Since active requestors are capable of issuing their own messages (in contrast to passive requestors) they can make use of the mechanisms defined within WS Security, WS Trust and WS Federations. 40

The most important message exchange patterns for a single sign on environment are the pattern for the initial sign on and use of a service (figure 3.16) and the pattern for signout (figure 3.17). Figure 3.17: Federated Sign out The message exchange pattern for sign on shows that the requestors first needs to get a security token from his IP/STS. Then he can use this token to request a security token from the IP/STS of the required service and finally use this service. In order to generate such messages, the <RequestSecurityToken> and <RequestSecurityTokenResponse> elements defined in the WS Trust specification should be used. In situations where federated sign out messages are needed, the message exchange pattern for sign outs can be used. First the requestor indicates to his IP/STS that he wants to sign out. After that, the IP/STS informs all other services about the requestor's sign out. The <SignOut> element defined in the WS Federation specification has to be used to generate such messages. As the WS Federation specification also defines models for pseudonym and attribute services, the profiles define message exchange patterns for these services, too. A more detailed description of these message exchange patterns is provided by [IBM03]. 3.2.3.3 Passive Requestor Profile The second extension to WS Federation is the Passive Requestor Profile. This profile defines how the federation model is applied to passive requestors such as web browsers that support the Hypertext Transfer Protocol HTTP. For more detailed information about this profile refer to [IBM03a]. 41

3.2.4 Security Assertion Markup Language The Security Assertion Markup Language (SAML 1.1) defines a framework for exchanging security information between online business partners. This framework provides methods for exchanging security assertions on the basis of XML. The charter of the Security Services Technical Committee (SSTC) at the Organization for the Advancement of Structured Information Standards (OASIS) states its purpose as to define, enhance, and maintain a standard XML based framework for creating and exchanging authentication and authorization information [OASIS03a]. The SSTC developed several use cases to derive the requirements for SAML [OASIS04]. The most important ones describe the SAML based solution for Web Single Sign On. Although the SSTC recognized the need for defining profiles on the usage of SAML in many different environments, they only provided two profiles for the main working environment: Web SSO in heterogeneous environments. Other profiles shall follow with the emergence of SAML 2.0. In the following the two profiles Browser/Artifact Profile and Browser/POST Profile will be described. For a more detailed view of SAML refer to [OASIS03] and [OASIS04]. 3.2.4.1 Browser/Artifact Profile Figure 3.18: Browser/Artifact Profile 42

The Browser/Artifact Profile is based on a pull model. Figure 3.18 illustrates the process: 1. The user has an authentication session on the local source site (asserting party). 2. The user wants to access a resource on the destination website and is directed there. In the HTTP message an HTTP query variable is passed (artifact). The artifact consists of a unique identity of the source site and a unique reference to the assertion. The artifact therefore enables the destination website to reference an assertion on a given website. 3. The destination site (relying party) needs to verify the identity of the user and sends a SAML request, containing the artifact, to the local site (asserting party) asking it what it can assert about the user. The assertions are returned in a SAML response. 4. Based on the given assertions the destination site can make any required authentication and authorization decisions. There are two possible scenarios for this process: 1. Source site first: The user first visits his local source site and is already authenticated at the source site before he uses a click through link to move on to the destination site. 2. Destination site first: The user visits the destination site first, however, he needs to be authenticated at the source site first before he can get access at the destination site. The SAML specification only defines the source site first use case. Figure 3.19 illustrates the scenario in greater detail. The process is as follows: 1. The user accesses the source website. 2. The source website performs an access check and determines that the user does not have a current session and requires the user to be authenticated. The user is challenged to authenticate. 3. The user supplies credentials. 4. If the authentication is successful, a session is created for the user and the appropriate screen is displayed for the user. 5. The user selects an option that means the user wants to access a resource on the destination website (The user may not be aware of this.). 43

6. The Inter site Transfer Service (ITS) generates an assertion for the user while also creating an artifact (asserting party). The ITS then sends an HTTP redirect to the user's browser containing the generated artifact. Figure 3.19: Source Site First Use Case for the Browser/Artifact Profile 7. On receiving the HTTP message containing the artifact, the destination website (relying party) will send a SAML request to the source website including the artifact. 8. The source website will send a SAML response providing an assertion based on the user's identity (created in step 6). If a valid assertion is received at the destination website, then a session will be created for the user. 9. The artifact receiver sends an HTTP redirect to the user containing a session identification. The user's browser processes the redirect message and requests the desired resource at the destination website providing the received session identification. 44

3.2.4.2 Browser/POST Profile The Browser/POST Profile is based on a push model and because of that does not have to rely on artifacts. Figure 3.20 will illustrate the process: Figure 3.20: Browser/POST Profile 1. The user has an authentication session on the local source site (the asserting party). 2. The user wants to access a resource on the destination website (the relying party). The source site provides an Hypertext Markup Language HTML form to the user containing the assertion. The form contains a button that causes a POST of the assertion to the destination site (this POST could be in the form of an auto submit action). 3. The destination website can then make any authentication and authorization decisions needed based on the received assertion. Again, as with the Browser/Artifact Profile, the SAML 1.1 specification provides only a specification for the Source site first situation. Figure 3.21 illustrates the scenario in more detail. 1. The user accesses the source website. 2. The source website performs an access check and determines that the user does not have a current session. The user is challenged to authenticate. 3. The user supplies the source website with the requested credentials. 45

4. If the authentication is successful, a session will be created for the user and the appropriate screen will be displayed to the user. Figure 3.21: Source Site First Use Case for the Browser/POST Profile 5. The user selects an option that means the user wants to access a resource on the destination website (The user may not be aware of this.). 6. The Inter site Transfer Service (ITS) generates an assertion for the user (asserting party). The ITS then sends an HTTP form to the user's browser containing a SAML response containing a signed SAML assertion. The HTTP form contains an submit action that will result in an HTTP POST. 7. The browser issues an HTTP POST containing the SAML response (relying party). 8. The destination website validates the signature of the SAML assertion. If it is valid, an HTTP redirect is sent to the user's browser causing it to access the desired resource (if he is authorized to do so). 3.2.4.3 Unspecified Profiles for the Destination site first use case Although the SAML 1.1 specification does not include a specification for the Destination site first use case, [OASIS04] provides a short introduction of this use case. 46

It differs from the Source site first use case, because the user first accesses the destination website. The solution is to redirect the user to the source website (asserting party) while saving the information about the desired access. The source website starts the already known authentication check, challenges the user and redirects him after a valid authentication back to the destination website. There the user's authorization is checked and if he is authorized given the access to the resource. 3.2.5 Additional important Standards 3.2.5.1 XML Signature XML Signature is a specification building part of the basis other Web Service standards can use, e.g. WS Security, if they need to ensure the integrity of an object. This specification describes how an XML message has to be signed, which signature standards (algorithms) can be used, and how this signature can be transported to the recipient. XML Signature allows the multiple signing of a message, so that any intermediary receiver can sign message content added. [W3C02a] describes the usage and requirements of XML Signature in a more detailed way. 3.2.5.2 XML Encryption XML Encryption is like XML Signature another part of the basis for Web Service standards, if they need to ensure message confidentiality. XML Encryption specifies how an XML message has to be encrypted, how XML elements are selected for encryption, how these elements have to be replaced by the encrypted content, and how the data can be extracted later, when it has arrived at the recipient. Included in this specification are the algorithms to be used for encryption. This includes symmetric and asymmetric algorithms as well. For a more detailed information about XML Encryption refer to [W3C02b]. 3.2.6 Applicability The enhancement of Web Service standards with prior mentioned standards appear to provide everything that is needed to build a Single Sign On solution premised on a service based architecture. WS Security provides the ability to transport information among the participants of the communication in a secure manner supported by XML 47

Signature and XML Encryption providing the basic functionality for secure communication. WS Trust improves SOAP with the ability to handle, request and transport tokens. Finally WS Federation provides the ability to manage the communication among federated domains. A very important advantage of these standards is the option to do everything needed transparent for the service. This allows to introduce the additional functionality without changing anything on services already implemented. In addition the provided functionality of these standards eases the difficulty of introducing security enhancements and improvements, so that a quick implementation seems to be possible. But finally there is a drawback: the availability. Although these standards have existed in there present condition for quite some time (WS Security and WS Trust since 2002, WS Federation since 2003) they are not accepted OASIS standards by now except WS Security which became an OASIS standard in April 2004. Because of that there is nearly no high level programming language that supports any of these standards and none that supports all of them. Obviously it would be possible to implement an application on SOAP level, but as long as these standards are not accepted by OASIS there can still be changes which would lead to an incompatible and proprietary solution. Moreover SAML does not provide a solution as it is still in a process of development and enhancement of features, which do not support needed functionality yet. In order to provide security for all services in a federated environment there can only be two possibilities: 1. Developing a solution based on the momentarily published documents of these standards (WS Security, etc.), which could lead to a complete rework later on to implement the standards correctly. Additionally not only the Web Services using this solution need future maintenance, the underlying model will need rework, too, if the standards improve and change during time. This can result in an amount of work which can hardly be estimated in advance. 2. Developing a service on a higher level so that the Web Services currently being used can benefit from the gained security. It will need a lot of precaution to minimize the necessary interaction between already existing Web Services and the new Web Service, so that the new security services are as transparent as possible for the 48

existing applications. Nonetheless this solution may result in additional work in the future to convert the security model to the finally reached standards, but this work has to be done only once and it may be possible to introduce the new security model slowly, one application at a time, while others still use the old model. The possibility to introduce the new model slowly into an existing environment is a consequence of the transparency of the services provided by WS Security, WS Trust, and WS Federation for the application. Comparing these two possibilities, it has to be emphasized that the second solution implies two major advantages: 1. Because of the possibility to use a high level programming language, the development can be much faster than a development that has to concentrate on many difficult details. This means, that improved security is gained sooner than with the other possibility. 2. Although both solutions imply work in the future if a use of the final standards is desired the second solution implies less work and a much easier way to introduce the changes. These two advantages apparently help to draw the conclusion that the second possibility should be favored, because with a comparable result it rapidly leads to security improvements and does that with less investment in work now and for the future. 49

4 Model for an Authentication Infrastructure Developing a single sign on solution with the ability to utilize the advantages of federations of trust is an extensive problem. Because of that the following sections will first describe the model for a single sign on solution only focusing on a single domain. Later on this model will be extended for federations of trust. Although the work of the standardization groups will not be utilized as a whole, there is information included in their standard proposals that should be taken into consideration. While the solution proposed here will focus on development in a high level language like Java, the standards discussed in the previous chapter focus on enhancements of SOAP. Therefore no details can be transferred to the new model, but the top level view allows to impart useful knowledge. This transfer of knowledge is mostly concentrated on the standards WS Security [IBM02], WS Trust [IBM02a] and WS Federation [IBM03b], while SAML [OASIS04] does not provide any additional knowledge for the solution, because it is focused too much on websites and their interaction. The main task of WS Security is to allow a secure message transfer between two communication endpoints. WS Trust extends this by defining trust between communication endpoints and how the scope of security can be extended from a single message to the whole communication. In addition the functionality for requesting and receiving security tokens is defined in WS Trust. On top of that WS Federation extends the scope from a single domain to multiple domains and explains the process of receiving and using security tokens (Active Requestor Profile). Figure 4.1: Knowledge Transfer As shown in figure 4.1 these standards build a stack of standards with three layers, which correspond with important tasks that these layers provide. During the course of 50

development it can be helpful to keep this security stack in mind as it provides the three steps needed to build a secure federated single sign on environment. 4.1 Single Domain Model As explained earlier the design process will first focus on a single domain model. Although the support for federations of trust must not be forgotten, the security stack in figure 4.1 explains why it is possible to concentrate on a single domain first. The following sections will describe what kind of service based single sign on environment will be used and which components will be contained in the model. Later on the communication flow and the effort that is needed to secure that communication will be explained. Finally there will be a description of the process of using a service, handling of authorization information and how delegation can be supported. 4.1.1 Service based Single Sign On In chapter 2.3 the different models for single sign on environment have been introduced. It is obvious that the client or server based solutions are not adequate for a new development, because of the drawbacks listed in table 2.1. On the contrary a service based single sign on model is favorable in a Web Service environment as Web Services provide a service oriented architecture. Token based and PKI based single sign on are the two options in a service based environment. Although PKI based single sign on provides equal capabilities compared to Token based single sign on, the public key infrastructure suffers from several disadvantages. At first there has to be a certificate for every user and for every service that can be used. Because of the asynchronous encryption used in a public key infrastructure there is not only a public key certificate, but a private key, too. This duality increases the amount of data that needs to be managed significantly. The possibility to store the private key on a smart card can be accepted as an advantage (it can easily be carried around and used at several different computers without the need to remember the log on credentials) or as a disadvantage (a smart card reader is needed at every computer and a smart card can be lost as easily as the log on credentials can be forgotten). The token based authentication architecture does not suffer from the same disadvantages. The encryption can use a symmetric process which slows down the 51

increase of keys in comparison to a public key infrastructure. Also the amount of log on credentials in a token based single sign on environment reduces itself to a single set of credentials, that minimizes the advantage of using smart cards. The capabilities of both architectures are similar and in an environment that could be built from scratch, none of the advantages or disadvantages would favor one of these technologies, but there are the requirements that have to be kept in mind. The model should support the use of existing authentication infrastructures like LDAP (Lightweight Directory Access Protocol) server or Unix PAM (Pluggable Authentication Modules). Using a PKI based infrastructure in combination with this authentication infrastructure would not be feasible as there is no mapping possible between a certificate pair and for example an entry in Unix PAM. With the requirements in consideration it is obvious that a token based architecture is the architecture of choice and has to be analyzed furthermore to extract the components that will be needed in such an environment. 4.1.2 Components In the following section the token based SSO architecture explained in detail in chapter 2.3.3 will be analyzed to reveal the components needed to develop the model (figure 4.2). Two components are to be recognized instantaneously: the client component and the server component. The client component is part of the client software with the task to handle anything needed to prove the identity of the client and to handle the process of accessing a service inside the domain. The server component is the complementary component inside the architecture. This component has to verify the identity of all clients and has to grant or deny access to services inside the domain. This explanation of the client and server components already indicates two other components: the credential database component and the service component. The database component will allow the authentication server to verify if a client's identity is correct and to decide if a client is allowed to access services inside the domain. The service component is part of the service software. The task of the service component is to ensure that only clients whom the authentication server granted access are allowed to utilize the service. 52

Additionally a directory component is needed to provide information for the clients about the available services and how they can be used. Finally there can be an optional component: the accounting service. This service receives information from the authentication servers, services and directories about the requests of the clients. This component enables the owner of that infrastructure to track the way users utilize the services statistically and if necessary to charge the user for any utilized service. Figure 4.2: Components After extracting the six necessary components, the communication flow between these components will be analyzed in the next section. 4.1.3 Communication Flow Figure 4.3: Communication Flow 53

In this section the flow of communication between the components (figure 4.3) will be inspected at first the communication between the two key components: client and server. Later on the communication between the server and the other components it has to exchange information which will be analyzed. Finally there will be an inspection of the communication between the client component and the other components, it interacts with. 4.1.3.1 Client And Server Communication In a token based single sign on environment the typical communication between client and server focuses on two steps: Identification and authentication of the client Requesting access to a service (authorization) During the authentication process the client presents his credentials which the server has to verify. If the presented credentials are correct, the server will return a security token to the client. This security token allows the client to prove in requests later on, that his identity has already been verified. If the client needs to access a service, he requests a service token from the server. During this request the client presents his security token to prove his identity. If the client is getting access by the server, the server will return a service token back to the client. The client has to present this token to the service he wants to access. 4.1.3.2 Additional Server Communication Besides the communication with the client component, the server component needs to communicate with the credential database. This database allows the server to verify the identity of a user requesting authentication by comparing the presented credentials with the credentials stored in the database. In addition the server may communicate with the accounting component. The server sends the accounting component information about which user needs what kinds of tokens (security tokens and service tokens) adding timestamps to allow an analysis during which periods of time the user has accessed the authentication infrastructure. 54

4.1.3.3 Additional Client Communication In addition to the communication with the server component the client needs to communicate with the service he wants to use. After receiving the service token from the authentication server, the client presents this token to the service in order to prove that he is allowed to access the service. After the token is verified by the service, the client is allowed to use the service. The client also communicates with the directory services. These directories are providing important data for the client. Because of these directories the client gets information about provided services and where these services can be accessed. 4.1.4 Secure Communication In order to ensure a secure authentication infrastructure it is important to protect the authentication process and the use of tokens from illegal access. This cannot only be done by comparing the presented user credentials in clear with the stored credentials in the authentication database. The following subsection will give a short introduction and overview of the possible attacks in a network and the different types of security services to protect the network communication. Later on the communication during the authentication process and the utilization of a service in the solution proposed here will be explained. 4.1.4.1 Security Attacks and Security Services Understanding the different types of attacks on network communication is essential to develop a secure authentication service. There are two categories of security attacks [Sta99]: passive attacks and active attacks. Passive attacks are: Release of message contents: This kind of attack is aiming on collecting confidential information included in the communication. Traffic analysis: The attacker observes the network communication in order to identify the nature of the communication and to identify and locate the users (or hosts) sending these messages. Because they do not include any message alteration, passive attacks are nearly undetectable. The emphasis on dealing with passive attacks is on prevention rather than on detection of an attack. In contrast to the passive attacks, the active attacks involve some modification of the data stream: 55

Replay: This kind of attack involves the passive capture of a data unit and its subsequent retransmission. Besides the possibility to produce an unauthorized effect on the target, the main goal of a replay attack is a masquerade attack. Masquerade: The goal of this kind of attack is to obtain extra privileges on the target by impersonating an entity that has these privileges (replay of a valid authentication sequence). Modification of messages: This attack tends to the modification of the message content. Denial of service: The attacker prevents or inhibits the normal use of communication facilities by overloading the network and the server with messages either to disable the network and the server or to degrade performance. Active attacks show the opposite characteristics of passive attacks. They are difficult to prevent, because most of the network communication travels across insecure connections and a physical protection is impossible. Therefore the focus is to detect active attacks and recover from disruption caused by them. The overview of different kinds of security attacks obviously indicates that different aspects of security are the main focus of the attack. In order to secure the network communication, security services have to address these aspects, which lead to different functions required of security services (the possible kinds of security attacks are mentioned in parenthesis): Confidentiality: The transmitted data has to be accessible only to the authorized recipient. This includes any form of disclosure including simply revealing the existence of an object. (Security attacks: release and modification of message contents, traffic analysis) Authentication: The main goal of this security service is to ensure that the origin of a message is correctly identified. (Security attacks: replay, masquerade, modification of messages) Integrity: Modification on transmitted data is only allowed to authorized parties, this also includes delaying or replaying of transmitted messages. (Security attacks: replay and modification of messages) 56

Access control: Access to information or resources is controlled in order to allow access only to authorized parties. (Security attacks: replay and masquerade) Availability: The assets of a computer system have to be available to authorized parties when needed. (Security attack: denial of service) These five functions of security services are important and while analyzing the network communication any further, these functions will be mentioned again to check if these aims are met. For a more detailed introduction on network security refer to [Sta99]. 4.1.4.2 Authentication In this subsection the authentication process will be analyzed in detail. During the following analysis, the transfer of encrypted data between communicating parties is needed many times and in order to provide a general notation, the notation defined in chapter 7 (Appendix A) will be used. Figure 4.4: Authentication Process During the authentication process (refer to figure 4.4) the claimed identity of the requesting user will be verified. In order to reach that aim, the following protocol steps are proposed: 1: C AS : U, T, L 2: AS C : {K, T C,STS }K U Figure 4.5: Authentication Protocol 57

In step 1 the client C transmits his username U, the timestamp T and the lifetime L to the authentication service AS in order to claim his identity. The authentication service AS responds in step 2 by sending back the key K and the security token T C,STS which is encrypted with the password K U of the user U. The term T C,STS = {U, STS, T, L, K}K STS is used to refer to a security token that is issued by the authentication service AS to be used by the client C to authenticate to a service token server STS to request a service token for a service the client is going to use. The key K STS is a shared secret between the authentication service AS and the service token server STS. Although these two services are regarded as separate services, it is possible to combine them to a single service. The key K will be used for encryption when the client C communicates with the service token server STS. During this authentication process the client never presents his credentials to the authentication service, because of that the authentication service is not able to compare the credentials with the saved credentials of the user. Nonetheless the authentication service replies to the user with a security token that enables the user to authenticate to the service token server, but this reply is encrypted with a key K U, the password of the identity the user claimed to be. Whether the correct user has claimed that identity or not, only the correct user is able to provide the correct password, i.e. the key for decryption, to take possession of the security token in the reply. Because of that a user's password is never transmitted across the network. After the specification of the authentication protocol, the quality of the security services will be evaluated: Confidentiality: The request (step 1) is sent in plain, but it obviously does not contain any relevant information for an attacker. The reply (step 2) is encrypted with the password of the claimed identity, because of that only the correct user gets access to the included information. It has to be mentioned here, that the length of the password is of importance in this protocol, because the strength of the encryption depends on the length of the password. In a study that observed password choices of approximately 7000 user accounts, almost 6% of the passwords were four characters or fewer in length [Spa92]. Obviously the strength depends on the length of the key used for encryption, but not entirely as there are critical factors like the quality of the password quality meaning in this situation: easy to guess or typical word (name of the girlfriend, etc.). In this regard the common problems with the quality of user 58

passwords are similar to the problems in this situation and cannot be solved by an authentication protocol. Authentication: Although the message sent in step 1 could be intercepted and then be replayed to the authentication service, there is nothing to be gained by that, because the reply will be encrypted with an unknown key. It would be possible for an attacker to launch an offline attack on the encrypted message and extract the key used for encryption, but this has to be done fast enough before the user has changed his password. Again the time necessary for a successful finding of the key used during encryption depends on the quality of the user's password. Integrity: Any change of the message sent in step 1 would lead to the server not sending a security token or encrypting the reply with a key the user does not know, the security token would be useless. If the message sent in step 2 would be altered, the client would have an error during decryption, which would lead to a retransmission of the login request. Access control: The access to any service is secured, because an attacker would first have to decrypt the reply in step 2. Again the time necessary for a successful finding of the key used during encryption depends on the quality of the user's password. Availability: It is still a difficult task to guarantee availability and as a consequence protect a service against a denial of service attack. The authentication process described here does not provide any protection against such an attack and especially the need to encrypt the reply would quickly result in heavy load on the authentication service and would at least lead to delayed responses of real authentication requests. The conclusion of the analysis has to be that there is the recommendation to change the user's password on a regular basis to ensure the security of the authentication process. Additionally the availability of the service has to be guaranteed, which is a much more difficult task. Providing additional authentication services on independent network nodes could at least decrease the impact of denial of service attacks and increase the availability of the authentication service. 4.1.4.3 Using a Service In this subsection the process of using a service will be described. Like in chapter 4.1.4.2 the communicating parties will only transfer encrypted data and in order 59

to provide a general notation, the notation defined in chapter 7 (Appendix A) will be used. The process of using a service is separated into two consecutive operations. First the client has to request a service token from the service token service (refer to figure 4.6) and then present that token to the corresponding service to authenticate himself (refer to figure 4.8). After that the client is allowed to utilize the service. Figure 4.6: Requesting Service Token For the process of requesting a service token and utilizing the corresponding service, the following protocol is proposed: 3: C STS : S, T C,STS, A C,STS 4: STS C : {T C,S, K'}K 5: C S : T C,S, A C,S 6: S C : A S,C Figure 4.7: Requesting a Service Token and mutual Authentication In step 3 the client C sends his request for a service token to the service token service STS. For this request the client C presents the already acquired security token T C,STS (refer to chapter 4.1.4.2), the name of the service S the client wants to use and an authenticator A C,STS = {U, T, L, N}K. An authenticator is a data record containing information that can be shown to have been recently generated using the session key known only to the client and the requested server. The nonce N is a serial number used 60

to prevent the replay of the message. The service token service STS has to store the last serial numbers used to validate the freshness of an authenticator. This communication is implicitly encrypted, because T C,STS and A C,STS are already encrypted. In step 4 the service token service STS responds to the requesting client C with a service token T C,S = {U, S, T, L, K'}K S, that can only be used by the client C for the service S (encrypted with the secret key K S, that is shared between the service token service STS and the service S), and a session key K' for the communication between the client C and the service S. The reply is encrypted with the secret key K, which the client received during authentication (refer to figure 4.5). The service token service STS gets access to the secret key K, because the secret key K is encrypted in the security token T C,STS the client presents to authenticate. Figure 4.8: Using a Service After step 4 the first part of the process to use a service is complete. The client has acquired everything needed to access the service. In step 5 the client C sends the service token T C,S and the authenticator A C,S = {U, T, L, N}K' to the service S. In step 6 the service S responds to the client C with the authenticator A S,C = {S, T, L, N 1}K'. The nonce N received by the service S is decreased by 1 and returned in step 6. This allows the service to ensure the freshness of the message by comparing the nonce with the already received nonces and it allows the client to check the correctness of the reply by the service, who had to successfully decrypt the authenticator A C,S received from the client to present the correctly decreased nonce in the authenticator A S,C. After that the client and the service are mutually authenticated and the client can start to use the service. 61

After the specification of the protocol proposed here, the quality of the security services will be evaluated: Confidentiality: During step 3 and 4 the security token T C,STS and the authenticator A C,STS are encrypted with different secret keys. The security token is encrypted using a secret key K STS that is only known to the authentication service AS and the service token service STS, while the authenticator is encrypted with a secret key K only known to the client C, the service token service STS and the authentication service AS. Because of the time an attacker would need to extract information of these tokens, the value of the gained information is minimal by the time of decryption, if the lifetime of the tokens is well chosen, i.e. short enough to be secure. During step 5 and 6 the service token T C,S and the authenticators A C,S and A S,C are sent. The service token is encrypted with a secret key K S only known to the service token service STS and the service S itself, while the authenticators are encrypted with the session key K' only known to the client C, the service S and the service token service STS. Again the information gained for the attacker after the time spent for extracting the information is of minimal value, because the lifetime of the tokens is short and the session keys should be invalid by then. Although the lifetime of the secret key K S is typically longer than the lifetime of the session key K', the extraction of K S is of no use, because it is only useful with a valid authenticator. Again it is important to mention that the lifetime of the session key has to be short enough to be secure. Authentication: In step 3 the authentication is being done by sending the security token T C,STS, preventing replay attacks by combining the security token with an authenticator A C,STS. The prevention of replay attacks depends on the lifetime of the authenticator if the lifetime is chosen too long then it might be possible for an attacker to replay that request. In order to prevent that, a sequence number N is used. If the authenticator A C,STS contains an old sequence number, then the replay attack is immediately recognized by the service token service STS. Without a valid security token and a valid authenticator it is impossible to gain access to a service token, that is still valid and only usable with a valid authenticator encrypted with a session key that has a short lifetime. During step 5 and 6 again an interception and replay of the transmitted data is of no use for an attacker, because of the short lifetime of the authenticator tokens A C,S and A S,C. Additionally the sequence number N enables the service and the client to ensure that no replay attack can be possible, because the attacker would provide an 62

authenticator with an already used sequence number. Even if the attacker could manage to provide a service that intercepts the communication between client and service, the false service would be identified, because he could not provide the correct authenticator token A S,C. Integrity: During all steps of the protocol proposed here, the data integrity is guarantied by the encryption of the data where a modification would be recognized during decryption. Additionally the short lifetime of the keys prevents the possibility of introducing new encrypted data with the key extracted by an attacker. The possibility of a successful replay attack has already been evaluated in the previous paragraph. Access control: Any access to services is restricted to clients that can provide the service token T C,S and a valid authenticator A C,S. Again it is important to mention that the lifetime of the session key has to be short enough to ensure security. Availability: As already explained during the evaluation of the first part of the authentication protocol, it is still a difficult task to guarantee availability and as a consequence protect a service against a denial of service attack. The authentication process described here does not provide any protection against such an attack and especially the need to encrypt the data before transmission would quickly result in heavy load on the service token service or the service requested by the client and would at least lead to delayed responses of real requests. The conclusion of the analysis must be that there is the recommendation to change the service's passwords on a regular basis to ensure security. Additionally the availability of the service token service and the services has to be guaranteed, which is a much more difficult task. Providing additional service token services on independent network nodes could at least decrease the impact of denial of service attacks and increase the availability of the service token service. 4.1.5 Authorization During the analysis of the protocol proposed here, authentication has been the main focus. For some services it might be enough to do access control (authorization) on the service token service, but a typical service usually provides several functions, that should not be accessible to all users authenticated, e.g. administrative functions. In order to provide the possibility to have a centralized access control, it is necessary to 63

extend the authentication protocol. Before a service's function can be executed, the user's authorization has to be checked, but the protocol does not include communication between the authentication / authorization service and the service: 1: C AS : U, T, L 2: AS C : {K, T C,STS }K U 3: C STS : S, T C,STS, A C,STS 4: STS C : {T C,S, K'}K 5: C S : T C,S, A C,S 6: S C : A S,C Figure 4.9: Communication in the Authentication Process Nonetheless the access control at the service needs to be provided with the authorization information. In order to supply authorization information, the service token T C,S = {U, S, T, L, K'}K S is extended to transmit the required authorization information A from the authentication / authorization service to the service: T C,S = {U, S, A, T, L, K'}K S. As the service token T C,S is encrypted with a secret key K S shared by the service token service and the corresponding service, this prevents alteration by the user to obtain extra privileges. 4.1.6 Delegation An additional feature of authorization, that can be very useful, is delegation. Delegation means that a user can give some of his access rights (or all of them) to another user for some period of time (refer to figure 2.12). There are two types of delegation rights (introduced in chapter 3.2.2, refer to table 3.7): delegatable access rights: give all rights to another user proxiable access rights: give some rights to another user The difference between delegatable and proxiable is that for proxiable a proxyserver is needed to decide about the access rights of the user, while delegatable can be realized by providing a security token of the originating user and the receiving user 64

impersonates this originating user. In order to delegate rights to another user, the originating user must have the right to delegate. 4.2 Extended Model for Federated Domains In chapter 4.1 the focus has been on the lower two layers of figure 4.1: secure messages and secure communication. With the protocol proposed in chapter 4.1 the basis for a federated domain model, the top layer of figure 4.1, is prepared. In the following subsections the extension of the model will be described. This includes extension to the communication protocol and the delegation of access rights. Additionally the problem of propagation of access rights for users from federated domains will be analyzed. 4.2.1 Extension of the Model An immediate consequence of the extension of the model on multiple domains, is that there are many authentication services every domain has to have one. The main focus of an authentication service is the authentication and authorization management of the local users. Figure 4.10: Components in a Multiple Domain Environment 65

Because of the extension a new task is added to this. Now there can be users from different domains wanting to access local services or a local user wanting to access a service in a different domain (figure 4.10). The possibility of access in non local domains is limited to users of domains that are combined in a federation of trust. The following subsections will describe what communication is needed to access services in remote domains. 4.2.2 Federation of Trust The extension on multiple domains does not introduce significant changes to the local communication protocol. The only thing that is added is the name of the domain D U of the user and the name of the domain D S of the service: 1: C AS : U, D U, T, L 2: AS C : {K, T C,STS }K U 3: C STS : S, T C,STS, A C,STS 4: STS C : {T C,S, K'}K 5: C S : T C,S, A C,S 6: S C : A S,C Figure 4.11: Adding Domain Information to the Authentication Process This also includes the following encrypted tokens: T C,STS = {U, D U, STS, T, L, K}K STS A C,STS = {U, D U, T, L, N}K T C,S = {U, D U, S, A, T, L, K'}K S A C,S = {U, D U, T, L, N}K' A S,C = {S, D S, T, L, N 1}K' This addition allows the authentication service to distinguish between users from different domains that share the same username. 66

In order to establish a federation of trust, both authentication services of the domains must be notified. This notification provides the authentication service with the information required to manage the authentication of users from the other domain. Figure 4.12: Communication in a Multiple Domain Environment The authentication service that has to handle the authentication request of a user from another domain needs to verify the identity of the user using the credential database of the other domain. This database is only accessible for the authentication service in the other domain, nonetheless the request must be processed and so the authentication services need to communicate and share information. The next subsections describe how the authentication services manage to find the corresponding authentication service that is responsible to handle requests for this user. 4.2.2.1 Direct Trust When an authentication service needs to find a corresponding authentication service to handle a request, the service checks the list of domains this authentication service has a federation of trust with (refer to figure 4.10). If these domains share a direct trust relation, then the corresponding domain will be found in that list of domains. After that the authentication service has to look up the related information for this relationship 67

(connection parameters, secret key, etc.) and proceed with the authentication process (described in detail in chapter 4.2.3). 4.2.2.2 Indirect Trust When an authentication service has checked the list of domains it has a federation of trust with and could not find the corresponding authentication service, the authentication service has to check the federation of trust for an indirect trust relationship. This is done by a routing table. Depending on the size of the federation of trust, the trust network can be a complex graph. If the domain can be found in the routing table that was generated at a previous request, then the request will be sent to the corresponding intermediary domain and there the next intermediary domain will be looked up until the corresponding domain is reached. If the domain can not be found in the routing table, then the routing table may be outdated and has to be generated again. Figure 4.13: Graph of a Federation of Trust 68

The routing table is to be generated by building a spanning tree of the trust network that is shown for example in figure 4.13. This tree is generated with the concept of the shortest path. This concept leads to a spanning tree with short communication paths ( short with respect to the amount of hops, i.e. communication nodes). In [Tan96] several algorithms to calculate this spanning tree are described. The resulting spanning tree for the highlighted authentication service in the example is shown in figure 4.14 (the resulting spanning tree is not unique and depends on the point of view: the highlighted authentication service). If the spanning tree is calculated, then the corresponding intermediary domain will be contacted as described above. Figure 4.14: Spanning Tree of the Trust Graph 69

4.2.2.3 Rejection of Trust In order to allow the local domain enhanced control of the indirect trust, the local domain can explicitly specify domains within the federation of trust, that will be accepted for granting authentication through indirect trust. This option is needed, because the local domain cannot control to which domains a federated domain is having a trust relationship with. This unknown domain may introduce severe danger to the security of the local domain (refer to chapter 4.2.5). 4.2.3 Authentication An authentication request from a user of a domain having a direct trust connection to the local domain, i.e. no intermediary domains, can be handled directly. 1: C AS : U, D U, T, L 2: AS ASR : {U, D U, T, L}K fed 3: ASR AS : {K, T C,STS, {K, T C,STS }K U }K fed 4: AS C : {K, T C,STS }K U Figure 4.15: Authentication across Domain Borders The client C from the remote domain requests the security token from the local authentication service AS in the same way as it would be from his authentication service ASR. The local authentication service AS transmits the request encrypted with the secret key K fed to the remote authentication service ASR handling the authentication for the domain the client C belongs to. The secret key K fed is specified during the establishment of the federation of trust. The authentication service ASR supplies the authentication service AS with the needed security token T C,STS. Because the local authentication service AS needs to access the security token, T C,STS = {U, D U, STS, T, L, K}K fed is encrypted with K fed instead of K STS. This security token T C,STS is returned to the client, who has to provide the correct key K U to decrypt the received data and extract the secret key K that has to be used for the communication with the local authentication service AS. After that the local service token service STS can handle any further communication with the client C by himself. 70

If the authentication request is from a user that does not belong to a domain with which the local domain has a direct trust relationship, the protocol must be extended in order to bridge the intermediary domains. 1: C AS : U, D U, T, L 1': AS ASI 1 : {U, D U, T, L}K fed,1 : : 1 (n) : ASI n ASR : {U, D U, T, L}K fed,n 2 (n) : ASR ASI n : {K, T C,STS, {K, T C,STS }K U }K fed,(n 1) : : 2': ASI 1 AS : {K, T C,STS, {K, T C,STS }K U }K fed,1 2: AS C : {K, T C,STS }K U Figure 4.16: Authentication utilizing Indirect Trust The extension of the protocol can be seen in the steps 1',..., 1 (n) and 2' and 2 (n). In order to indicate that there can be more than one intermediary authentication service ASI, these steps are separated by dots in figure 4.16. The process of finding an intermediary ASI i, i=1,..,n, is explained in chapter 4.2.2.2. In order to bridge these intermediary communication nodes, the transmitted data is encrypted with the corresponding secret keys K fed,i, i=1,..,n 1, that these intermediary communication nodes share with their predecessors respectively successors (refer to figure 4.17 showing an example). 71

Figure 4.17: Authentication using Indirect Trust After the security token is sent to the requesting user, the authentication process is finished. The further requests of this user to receive any needed service tokens can then be sent directly to the local service token service STS, that handles these requests without further interaction with the remote authentication services ASR i, i=1,..,n. 72

4.2.4 Using a Service The process of requesting a service token and using a service needs no further extension. The introduced domain D U of the user U in chapter 4.2.2 and the explained extension of the authentication process is sufficient to use a service across domain borders. 4.2.5 Mapping of User Roles Chapter 4.1.5 is related to the problem how authorization information can be transmitted from the authorization service managing the access control to the service that is controlled by that authorization service. Because the service token service provides the service token for any user local or from federated domains this transmission is still applicable. Figure 4.18: Mapping of User Roles The difference between the single domain solution and this expanded model is that the service token service does not have access to the access control of a user from a federated domain. Additionally there is the problem, that the service token service can not utilize this information from a federated domain, because the operating system 73

might vary from the local operating system, i.e. the access control information is not comparable with the access control information in the local domain, and the user might impersonate a user role that does not exist in the local domain, i.e. no access rights can be identified with this user. The solution proposed here uses a mapping of user roles (refer to figure 4.18 as an example). This mapping is assigning a user role of a federated domain to a user role in the local domain. The mapping only works in one direction: from the federated domain to the local domain. Advantages of this solution: A user impersonates a user group of the federated domain not being mapped, has only access privileges on guest level in the local domain. The access rights of federated users in the local domain are set and controlled by the local domain. Because of the unidirectional mapping, each domain of a federation can control the access rights autonomously. The major disadvantage of the solution is originating from the possibility of allowing loops in the federation of trust network. If a mapping increases the access rights of a user role, it might be possible to gain access rights because of a loop with larger privileges than the user originally should have in the local domain. This disadvantage is considered to be very serious, because this problem can arise from a mapping that cannot be controlled by the local domain, i.e. originating from an intermediary domain in the loop of the trust network. In order to protect the domain from this threat, the possibility of rejection of trust has been introduced in chapter 4.2.2.3. 4.2.6 Delegation The extension of the model to multiple domains does not influence the ability to delegate access rights to other users (refer to chapter 4.1.6). A user from a federated domain can receive access rights through delegation in any domain that is part of the federation of trust. 74

4.3 Conclusion This chapter described the design of the model of an authentication infrastructure supporting single sign on and federations of trust. In order to reach this aim, the focus has been at first on a single domain solution. The principal aim has been the security of the communication between the different components. Therefore the possibilities for security attacks and the functions of security services have been explained. After that the communication and the encryption of the communication has been described. The section has been concluded with the methods to transport authorization information and to delegate access privileges. Later on the focus has been on the extension on federations of trust. In order to utilize federations of trust the authentication protocol has been extended to allow users access from remote domains. Therefore the concept of authentication domains has been introduced to the process of obtaining security tokens. In addition, the mapping of user roles has been introduced to allow an easy and dynamic assignment of access privileges. The next chapter will focus on the implementation of a prototype that is based on this model to prove the usability of the model. 75

5 Realization of the Model In this chapter the implementation of a prototype on the basis of the model proposed in chapter 4 will be described. This description is starting with an overview of the prerequisites for the implementation. Later on the structure of the realization and the realization itself will be depicted, concluding with a short section focusing on future improvements. 5.1 Basis of the Implementation The prototype of the model has to reach certain aims explained in chapter 1.2, because of that the programming language is Java. In order to build an authentication service utilizing Web Services there are several Java Extensions needed. These extensions will be described shortly in the next subsections. 5.1.1 Java Web Services Developer Pack The Java Web Services Developer Pack (JWSDP) [Sun04] in version 1.3 enhances the programming language Java with the ability to develop software that uses Web Services. There are several different approaches to build a Web Service based on this developer pack. One of these approaches is the Java API for XML based RPC (JAX RPC) that allows the development of software that uses remote functions of Web Services like remote procedure call (RPC). This approach will be used in the realization, while SOAP with Attachments API for Java (SAAJ), that would allow direct access to SOAPmessages, will not be used, because of the reasons explained in chapter 3.2.6. A Web Service using the Java API for XML based RPC allows client software written in a different language to use this Web Service. This interoperability is a result of the usage of SOAP, that defines standards for XML messaging and the mapping of data types so that applications adhering to these standards can communicate with each other, and WSDL, that describes a Web Service in a standardized way using an XML document making the description portable. The standards SOAP and WSDL have been described in greater detail in chapter 3.1. JAX RPC hides the complexity of SOAP messages from the application developer. On the server side, the remote procedures have to be specified by defining an interface written in Java. A class implementing this interface build the server application. On the 76

client side a proxy is automatically generated, representing the service on the server side. This service can be used by invoking methods on the proxy. The developer does not generate or parse SOAP messages. The API calls and responses will be converted to and from SOAP messages by the JAX RPC runtime system. The Java Web Services Developer Pack includes the servlet container Tomcat, that will be used to run the authentication servers and the services that use the authentication infrastructure. 5.1.2 Java Naming and Directory Interface The Java Naming and Directory Interface (JNDI) [Sun04a] in version 1.2.1 is an API that is included in the Java 2 SDK since version 1.3. This API is defined to be independent of any specific directory service implementation and provides naming and directory functionality to Java. The Java 2 SDK includes several service providers for naming or directory services. One of them is the Lightweight Directory Access Protocol (LDAP) that shall be used in the following to provide access to already existing authentication infrastructures. 5.1.3 Java Cryptography Extension The Java Cryptography Extension (JCE) [Sun04b] in version 1.2.2 is an API that is provided as an extension to the Java 2 SDK since version 1.2. JCE provides a framework and implementations for encryption, key generation and key agreement, and message authentication code algorithms. This extension will provide the needed cryptographic functions to encrypt and decrypt the tokens used in the model. 5.2 Structure Figure 5.1: Package Structure 77

The realization of the model is structured into five different packages: authclient, authserver, service, token and util. These packages represent different components of the model described in chapter 4. The figure 5.1 shows the tasks of the packages that will be described in the following subsections. 5.2.1 Client The package authclient includes the class AuthClient. This class realizes the functions a client will need to utilize the single sign on authentication service. This includes the function to log on to the authentication service and functions to request service tokens and send these tokens to the corresponding services. Some supporting functionality is implemented in the package util and used in the class AuthClient. 5.2.2 Server The package authserver includes two classes: AuthServerImpl and AuthServer. The class AuthServerImpl implements the interface AuthServerIF, that includes all the procedures that can be invoked at the authentication server. AuthServerImpl uses the class AuthServer that provides the procedures needed for an authentication server. This functionality is encapsulated from the class AuthServerImpl to allow an easy instantiation of the authentication server and to allow multiple instances of the authentication server on the same servlet container. In addition the class AuthServer includes the functionality of a service token service that is combined to one service in this implementation. 5.2.3 Service The package service includes two classes: ServiceImpl and Service. The class ServiceImpl implements the interface ServiceIF, that includes the procedures provided by the service. The class Service is the implementation of the authentication operations that is invoked by the ServiceImpl. This separation allows the encapsulation of the procedures that provide the authentication verification and handle the access control. 78

5.2.4 Communication The package token includes eight classes: Token, TGT, TGTResponse, ST, STResponse, Authenticator, and FederationTGTResponse. These classes represent the basis for the communication between the different components (refer to figure 5.1). Each of this classes is either a complete network message or a part of a network messages send between the components. The class Token is the base class of all the other classes in this package. This class already contains the typical member variables that need to be transferred between the authentication parties and the functions needed to encrypt and decrypt the tokens. The class TGT represents the security token issued by the authentication service which is used to proof successful authentication. The class TGTResponse is a token that includes a security token and information needed by the client (refer to chapter 4.2.3). The class ST represents a service token issued by the service token service. This token is used to proof the access rights of the user wanting to use that service. STResponse is a token that includes a service token and information needed by the client (refer to chapter 4.1.5). The Authenticator is a token containing information that can be shown to have been recently generated and encrypted with a shared secret known only to the sender and the recipient. This class allows to prove the freshness of transmitted information. The class FederationTGTResponse is a token that includes a security token and information needed by the authentication service evaluating the request. 5.2.5 Supporting Classes The package util includes five classes: AuthUtilities, TokenCache, KeyElement, TokenElement and WebserviceConnectionData. This package includes several classes supporting the authentication process. They provide several functions that are needed by all components included in the authentication process. The class AuthUtilities includes static methods supporting the evaluation of authentication requests. The class TokenCache is a container for the authentication client needed to store the received secret session keys (KeyElement) and tokens (TokenElement). 79

5.3 Implementation In this chapter the realization of the three main components will be explained. The main focus will be on the interaction between the authentication infrastructure and an application making use of these components. 5.3.1 Client The client component is the interface between the authentication infrastructure and an application that wants to access resources protected by this authentication infrastructure. This subsection will first explain the process of typical operations from the client side view (sign on, accessing a resource, etc.) and after that focus on the application side view of the authentication client. 5.3.1.1 Authentication Process A typical authentication process begins with the log on of the client. This is being done by sending the username and domain (beside other information that will not be mentioned all the time as they are not needed to understand the process) to the authentication server. If the data sent is valid, the server will respond with an encrypted token. This token is a container for the security token. The client has to use the user's password to decrypt that token and access the security token, if the decryption was successful, i.e. the user's password was correct. The security token will be stored in the TokenCache to allow access to the security token later on. If the client wants to access a resource, a corresponding service token will be needed. In order to obtain such a token, the client requests a service token from the service token service integrated in the authentication server. During this request the security token has to be presented to the server. If the security token is valid and the user is allowed to have general access to the service, a service token will be issued. The client stores that service token in the TokenCache for further use. Now the application can use the service token to authenticate itself to the service and access the service. The TokenCache is of great importance during this process. The TokenCache does not only store security and service token (as in the above described initial authentication process), it also would be checked before a request, if that token was already obtained by the client. This allows reuse of tokens that are still valid. 80

5.3.1.2 Integration On the application side there is only a simple interface to the authentication client (figure 5.2) that handles all the needed authentication processes. The login() procedure first checks the TokenCache, whether the needed security token has already been obtained. If the token is not stored in the cache, then the corresponding authentication server will be contacted to request the security token. After storing the token in the TokenCache, the application is informed that the authentication was successful. login() requestservice() useservice() Figure 5.2: Authentication Client Interface The requestservice() procedure is invoked to request a service token from the authentication server. Before the authentication server is contacted, the TokenCache will be checked if the desired service token has already been obtained before. After the authentication client has got the service token (from the TokenCache or the authentication server), the application is informed of the success of the process. The useservice() procedure handles the mutual authentication between client and service. The service token needed will be obtained from the TokenCache and sent to the service. If the process is finished successfully, the application will be informed and can now use the service (if the access rights are sufficient). 5.3.2 Server The authentication server component does not have any interface with an application. Therefore the following subsection will focus on the internal process of authentication. 5.3.2.1 Authentication Process When the authentication server receives a request for a security token, the username will be looked up in the authentication infrastructure used, e.g. LDAP server, and the user's password will be retrieved. If this retrieve operation is successful, i.e. the user 81

belongs to the local domain, the security token will be generated and returned. If the user does not belong to the local domain, the authentication server has to check if this domain is a federated domain and contact the corresponding authentication server by means of the federation of trust. If this operation is finished successfully, the authentication server will return the received information to the client (the reverse view, i.e. a federated authentication server wants to authenticate a user, will be explained later). When the authentication server receives a request for a service token, the presented security token will be checked for validity. If the token is valid, a service token will be generated that includes the authorization information. This information has to be looked up in the authorization database. When the authentication server receives an authentication request from a federated authentication server, the server has to look up the user's password and generate a security token, if the username is valid. This security token is returned to the federated authentication server encrypted with the user's password which is unknown to the federated authentication server. In addition the generated secret session key contained in the security token will be returned to the federated authentication service, because of the password being unknown to the federated authentication service, the federated service cannot generate a valid response for the user itself and the secret session key has to be included in the token returned. As mentioned before the authentication server has to contact the corresponding authentication server to process the authentication request from a user who does not belong to the local domain. In order to find the corresponding authentication server the authentication server has to generate a routing table that describes the view of the authentication server on the trust network (refer to figure 4.13). The view is generated by flooding, this means the authentication server sends a request to build a spanning tree of the network graph to all authentication servers it maintains a direct trust relationship. These send themselves such a request to their authentication servers they maintain a direct trust relationship. This process continues until: 1. An authentication server has no other direct trust connection. 2. An authentication server receives a second request from the same originator. 82

3. All authentication servers that received the request already got another one before this request. If no other direct trust connection exists the authentication server responds to the requestor with the domain name of the authentication server. All authentication servers on the route to the final authentication server add their domain name to the reply and respond to their requestors. If an authentication server receives a second request it informs its predecessor about the first request. The predecessor will then wait for the replies of the other authentication servers the predecessor informed of the request. If an authentication server receives only replies that the successors got the request first, then the authentication server will act like there are no direct trust connections (refer to 1.) This process will lead to a spanning tree of the trust network (refer to figure 4.14). After a successful request the authentication server will store the routing table containing the names of all domains in the trust network combined with the corresponding direct trust connection. When all authentication servers have finished this process, every authentication server has a partial view of the trust network that allows them to send their requests to the correct intermediary authentication server until the requests reach their destinations. 5.3.3 Service The service component is the interface between the authentication infrastructure and the service making use of the authentication infrastructure. This subsection will first explain the process of typical authentication operations and then focus on the integration of the authentication infrastructure into a service. 5.3.3.1 Authentication Process The authentication process for a service only consist of the mutual authentication between client and service. The service receives the service token and an authenticator from the client. If the authenticator is valid, i.e. the lifetime is not exceeded and the nonce has not been used before (refer to chapter 4.1.4.3), the service returns its own authenticator to authenticate itself to the client. After that the client can start using the service, if the access rights included in the service token allow the desired operations. 83

5.3.3.2 Integration The integration of the authentication infrastructure into a service is much more difficult in contrast to the integration into a client application. The class Service includes the authentication operations, i.e. the process of mutual authentication between client and service. This is done transparently by invoking the method requestservice() of Service. After the authentication process the authorization information is present at the service, but the interpretation and usage of this information is done by the service itself, because the content of the authorization information depends on the service. Figure 5.3: Structure of a Service In order to have a transparent access control, the solution proposed here as shown in figure 5.3 uses a service that consists of three components: the authentication control, the access control and the service itself. While the authentication is included in the class Service, the access control is handled by the ServiceImpl class. The class ServiceImpl provides the same interface as the service itself, but handles the access control before invoking the real service functions. An example of possible authorization information is an array of boolean values that provides a boolean for every function the service provides. If the corresponding boolean of a function is true, then the access control will be allowed to invoke the real service function. 84

This is only a simple example of the possibilities how the solution proposed here can handle access control. More sophisticated possibilities can be implemented, too, because the authentication infrastructure only provides the authorization information, but is not interpreting the information. 5.4 Possible Improvements Although the implementation of the model is based on actual knowledge in authentication and cryptography, there are several points, where the quality of the whole infrastructure can be improved. First of all the security of further communication with a service after service and client have been mutually authenticated has to be ensured. Either in the model or in the realization nothing is said about this part of the communication as it is no longer a task of the authentication infrastructure, but it must be mentioned that the communication after the authentication process has to be encrypted in some way to prevent the release of message content. Sending any further communication in clear, the purpose of an authentication system is at least questionable. A second improvement has been suggested before: the regular changing of security keys and passwords. This changing can be done on a regular basis by the authentication service for the secret keys shared between different (authentication) services. However this cannot be done automatically for the users' password. It is recommended to introduce a process into the authentication infrastructure that forces the users to change their passwords. 85

6 Summary and Outlook Web Services are capable of providing all kinds of services to their clients. Every client can use a Web Service without even knowing anything about the implementation of the Web Service. The Hypertext Transfer Protocol (HTTP) is one of the protocols to transmit SOAP messages, the communicational basis of Web Services. If there are Web Services that are not only used for local purposes, security cannot be ensured solely by using a standard corporate firewall, because every communication will use the HTTP port and a firewall is not capable of distinguishing between the clients that are allowed to use the Web Services and those that are not. In order to secure such a Web Service infrastructure a different approach has to be used. An objective of this diploma thesis was to build an authentication infrastructure that supports single sign on and federations of trust on the basis of Web Services. Therefore the concept of single sign on has been analyzed and the different characteristics have been compared. This analysis showed as a result that a service based single sign on solution is the best approach to build a new authentication infrastructure. As federations of trust are to be supported by the new authentication infrastructure, this has been analyzed, too. A major advantage of federations of trust is the enhancement of dynamic interaction of different trust domains. Using an international standard supporting federations of trust would ensure possible interaction between different environments. Several standardization groups started to build up a framework for a secure authentication service that would make use of federations of trust with standards enhancing the current Web Service standards. This work is still in progress and cannot be used as a whole, therefore the basic ideas have been extracted and transferred on a new solution proposed here. These basic ideas showed that an authentication infrastructure has to be build on message security, communication security and multiple domain communication. At first the focus of developing a solution has been on the revelation of the different components needed for an authentication infrastructure. Later on the communication between these components and the precautions to ensure a secure communication became a prime aspect. Nonetheless the aspects of security attacks against this authentication infrastructure have been analyzed to show that this infrastructure can provide reasonable security. 86

In addition, the authentication infrastructure has been enhanced with the ability to transport authorization information from a central service to the services a user can access. This service allows the central administration of access control not only for users belonging to the local domain, but to users belonging to federated domains by using a mapping of user groups to transfer access control from a federated authentication infrastructure to the local domain. A prototype of this model has been realized using the Java programming language and the Java Web Services Developer Pack. The Java Naming and Directory Interface has been used to utilize an LDAP server containing the credentials for the authentication. The Java Cryptography Extension provides the necessary algorithms to encrypt and decrypt the transmitted data. As mentioned before, there are two important aspects that require future work. One is the protection of communication between a client and its requested service after they got mutually authenticated and the other is the change of users' passwords on a regular basis to enhance security even more. 87

7 Appendix A: Conventions of Notation for Encryption The notation used to describe the encrypted communication in the solution proposed here, is suggested by [Opp96]. Capital Letters, such as A, B, C,..., are used to refer to principals, whereas the same letters put in italics are used to refer to the corresponding principal identifiers. K is used to refer to a secret key The term {m}k is used to refer to a message m that is encrypted with the secret key K. During decryption the same key K is used, so {{m}k}k = m. T is used to refer to a timestamp. Timestamp subscripts are used to distinguish from different timestamps or to imply a temporal ordering. N is used to refer to a nonce. A nonce is a quantity that any user of a cryptographic protocol is supposed to use only once. A nonce can be a sequence number, a timestamp or a random number. In order to describe the exchange of information between communicating parties, the notation used is: i: P Q : m This notation refers to step i, in which P is assumed to transmit a message m to Q. 88

8 Literature [Andr04] Peter Andrews, Single sign on Balancing convenience and security, seen April 2004 http://www 1.ibm.com/mediumbusiness/resources/ businessarticles/article/howtoarticle.wss?id=4066 [Boo03] Booth, D., Le H egaret, P., Liu, C. K., Web Services Description Language (WSDL) Version 1.2 Part 0: Primer, Editors copy, 01.06.2003, http://www.w3.org/2002/ws/desc/wsdl12 primer. [CAU04] Web Service Firewalls at Christian Albrechts University in Kiel, Germany, http://www.comsys.informatik.uni kiel.de/ [Cler02] Clercq, Jan de, Single Sign On Architectures, Infrastructure Security, International Conference, InfraSec 2002, Bristol, UK, October 2002 Proceedings S.40 58 [Fuji04] Fujitsu Siemens Security, Enterprise Security, 2004, http://www.fujitsu siemens.de/partner/security/index.shtm [IBM02] IBM, Specification: Web Services Security (WS Security), 05.04.2002, http://www 106.ibm.com/developerworks/webservices/library/ws secure/ [IBM02a] IBM, Specification: Web Services Trust Language (WS Trust), 18.12.2002, http://www 106.ibm.com/developerworks/library/ws trust/ [IBM03] IBM, Specification: WS Federation: Active Requestor Profile, 08.07.2003, http://www 106.ibm.com/developerworks/webservices/library/ws fedact/ [IBM03a] IBM, Specification: WS Federation: Passive Requestor Profile, 08.07.2003, http://www 106.ibm.com/developerworks/webservices/library/ws fedpass/ [IBM03b] IBM, Specification: Web Services Federation Language (WS Federation), 2003, http://www 106.ibm.com/developerworks/library/ws fed/ [IETF85] Internet Engineering Taskforce, File Transfer Protocol FTP, 1985, http://www.ietf.org/rfc/rfc0959.txt [IETF96] Internet Engineering Taskforce, Multipurpose Internet Mail Extensions MIME, 1996, http://www.ietf.org/rfc/rfc2045.txt [IETF99] Internet Engineering Taskforce, Hypertext Transfer Protocol HTTP/1.1, 1999, http://www.ietf.org/rfc/rfc2616.txt [IETF01] Internet Engineering Taskforce, Simple Mail Transfer Protocol SMTP, 2001, http://www.ietf.org/rfc/rfc2822.txt 89

[OASIS03] Organization for the Advancement of Structured Information Standards (OASIS), Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1, 02.05.2003, http://www.oasis open.org/committees/download.php/1874/sstc saml bindings 1.1 draft 04.pdf [OASIS03a] Organization for the Advancement of Structured Information Standards (OASIS), Charter of the Security Services Technical Committee, 11.11.2003 http://www.oasis open.org/committees/security/charter.php [OASIS04] Organization for the Advancement of Structured Information Standards (OASIS), Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1, 11.05.2004, http://www.oasis open.org/committees/download.php/6837/sstc saml tech overview 1.1 cd.pdf [Opp96] Opplinger, Rolf, Authentication Systems for Secure Networks, Artech House, Inc., 1996 [Spa92] Spafford, E., Observing Reusable Password Choices, Proceedings, UNIX System Symposium III, September 1992 [Sta99] Stallings, William, Cryptography and Network Security, Principles and Practice, Second Edition, Prentice Hall International, 1999 [Sun04] Sun Microsystems, Java Web Services Developer Pack (JWSDP), seen July 2004, http://java.sun.com/webservices/jwsdp/index.jsp [Sun04a] Sun Microsystems, The Java Naming and Directory Interface (JNDI) Tutorial, seen July 2004, http://java.sun.com/products/jndi/tutorial [Sun04b] Sun Microsystems, Java Cryptography Extension (JCE), seen July 2004, http://java.sun.com/products/jce/ [Tan96] Tanenbaum, Andrew S., Computer Networks, Third international edition, Prentice Hall International, 1996 [TheO99] The Open Group, Security Forum, http://www.opengroup.org/security/sso/, 1999 [W3C01] World Wide Web Consortium W3C, Web Services Description Language (WSDL) 1.1, 15.03.2001, http://www.w3.org/tr/wsdl [W3C02] World Wide Web Consortium W3C, Web Services Architecture W3C Working Draft, 14.11.2002, http://www.w3.org/tr/2002/wd ws arch 20021114/. 90

[W3C02a] World Wide Web Consortium W3C, XML Signature Syntax and Processing W3C Recommendation, 12.02.2002, http://www.w3.org/tr/xmldsig core/ [W3C02b] World Wide Web Consortium W3C, XML Encryption Syntax and Processing W3C Recommendation, 10.12.2002, http://www.w3.org/tr/xmlenc core/ [W3C03] World Wide Web Consortium W3C, extensible Markup Language XML, 2003, http://www.w3.org/xml/ [W3C03a] World Wide Web Consortium W3C, SOAP Version 1.2: Primer W3C Recommendation, 24.06.2003, http://www.w3.org/tr/soap12 part0/ [W3C04] World Wide Web Consortium W3C, Web Services Architecture W3C Working Draft, 11.02.2004, http://www.w3.org/tr/2004/note ws arch 20040211/ 91