Diplomarbeit. Single Sign On In Web Service Scenarios

Size: px
Start display at page:

Download "Diplomarbeit. Single Sign On In Web Service Scenarios"

Transcription

1 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 Kaiserslautern

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

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

4

5 Table of Contents 1 Introduction Motivation Objectives Structure Identification and Authentication in a Computer Network Getting Access to Objects Multi Sign On Problems with Multi Sign On Single Sign On What is Single Sign On? Possible Solutions Service based Single Sign On in Detail Problems and Risks Federation of Trust Models of Federation Pros and Cons of Federation Single Sign On with Web Services What are Web Services? SOAP WSDL Standards enhancing SOAP WS Security WS Trust WS Federation Security Assertion Markup Language Additional important Standards Applicability Model for an Authentication Infrastructure Single Domain Model Service based Single Sign On Components Communication Flow

6 4.1.4 Secure Communication Authorization Delegation Extended Model for Federated Domains Extension of the Model Federation of Trust Authentication Using a Service Mapping of User Roles Delegation Conclusion Realization of the Model Basis of the Implementation Java Web Services Developer Pack Java Naming and Directory Interface Java Cryptography Extension Structure Client Server Service Communication Supporting Classes Implementation Client Server Service Possible Improvements Summary and Outlook Appendix A: Conventions of Notation for Encryption Literature

7 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

8 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

9 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, s, 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

10 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

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

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

13 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

14 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

15 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

16 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

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

18 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

19 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

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

21 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

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

23 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

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

25 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

26 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

27 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

28 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] 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

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

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

31 <UsernameToken Id= > <Username> </Username> <Password Type= > </Password> </UsernameToken> Figure 3.3: UsernameToken Element or Attribute /UsernameToken /UsernameToken /Username /UsernameToken /Password /UsernameToken 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

32 Element or Attribute /BinarySecurityToken /BinarySecurityToken /BinarySecurityToken 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. 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 security token. Table 3.3: SecurityTokenReference The <ds:keyinfo> element (defined in the XML Signature specification, refer to chapter ) can be used for carrying key information. It is allowed for different key types and for future extensibility. 28

33 Message Integrity The <Security> header block can be extended by the sub element <ds:signature> (defined in the XML Signature specification, refer to chapter ) 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 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] 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] 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

34 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

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

36 Element or Attribute /RequestSecurityToken /RequestKeyType /RequestSecurityToken /RequestKeySize /RequestSecurityToken /RequestSignatureAlgorithm /RequestSecurityToken /RequestEncryption /RequestSecurityToken /RequestProofEncryption /RequestSecurityToken /UsePublicKey /RequestSecurityToken /RequestSecurityToken /UseKeyRef /RequestSecurityToken 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

CS 356 Lecture 28 Internet Authentication. Spring 2013

CS 356 Lecture 28 Internet Authentication. Spring 2013 CS 356 Lecture 28 Internet Authentication Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control Lists

More information

WEB SERVICES SECURITY

WEB SERVICES SECURITY WEB SERVICES SECURITY February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in part without

More information

Grid Delegation Protocol

Grid Delegation Protocol UK Workshop on Grid Security Experiences, Oxford 8th and 9th July 2004 Grid Delegation Protocol Mehran Ahsant a, Jim Basney b and Olle Mulmo a a Center for Parallel Computers,Royal Institute of Technology,

More information

IBM SPSS Collaboration and Deployment Services Version 6 Release 0. Single Sign-On Services Developer's Guide

IBM SPSS Collaboration and Deployment Services Version 6 Release 0. Single Sign-On Services Developer's Guide IBM SPSS Collaboration and Deployment Services Version 6 Release 0 Single Sign-On Services Developer's Guide Note Before using this information and the product it supports, read the information in Notices

More information

An Oracle White Paper Dec 2013. Oracle Access Management Security Token Service

An Oracle White Paper Dec 2013. Oracle Access Management Security Token Service An Oracle White Paper Dec 2013 Oracle Access Management Security Token Service Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only,

More information

Technik und Informatik. SOAP Security. Prof. Dr. Eric Dubuis Berner Fachhochschule Biel. Version April 11, 2012

Technik und Informatik. SOAP Security. Prof. Dr. Eric Dubuis Berner Fachhochschule Biel. Version April 11, 2012 SOAP Security Prof. Dr. Eric Dubuis Berner Fachhochschule Biel Version April 11, 2012 Overview Motivation Transport security versus SOAP Security WS-Security stack overview Structure of secured SOAP messages

More information

02267: Software Development of Web Services

02267: Software Development of Web Services 02267: Software Development of Web Services Week 11 Hubert Baumeister huba@dtu.dk Department of Applied Mathematics and Computer Science Technical University of Denmark Fall 2015 1 Contents WS-Policy Web

More information

Entrust Managed Services PKI. Getting started with digital certificates and Entrust Managed Services PKI. Document issue: 1.0

Entrust Managed Services PKI. Getting started with digital certificates and Entrust Managed Services PKI. Document issue: 1.0 Entrust Managed Services PKI Getting started with digital certificates and Entrust Managed Services PKI Document issue: 1.0 Date of issue: May 2009 Copyright 2009 Entrust. All rights reserved. Entrust

More information

Security Digital Certificate Manager

Security Digital Certificate Manager System i Security Digital Certificate Manager Version 5 Release 4 System i Security Digital Certificate Manager Version 5 Release 4 Note Before using this information and the product it supports, be sure

More information

This Working Paper provides an introduction to the web services security standards.

This Working Paper provides an introduction to the web services security standards. International Civil Aviation Organization ATNICG WG/8-WP/12 AERONAUTICAL TELECOMMUNICATION NETWORK IMPLEMENTATION COORDINATION GROUP EIGHTH WORKING GROUP MEETING (ATNICG WG/8) Christchurch New Zealand

More information

Secure Authentication and Session. State Management for Web Services

Secure Authentication and Session. State Management for Web Services Lehman 0 Secure Authentication and Session State Management for Web Services Clay Lehman CSC 499: Honors Thesis Supervised by: Dr. R. Michael Young Lehman 1 1. Introduction Web services are a relatively

More information

Enterprise Digital Identity Architecture Roadmap

Enterprise Digital Identity Architecture Roadmap Enterprise Digital Identity Architecture Roadmap Technical White Paper Author: Radovan Semančík Date: April 2005 (updated September 2005) Version: 1.2 Abstract: This document describes the available digital

More information

Security Digital Certificate Manager

Security Digital Certificate Manager IBM i Security Digital Certificate Manager 7.1 IBM i Security Digital Certificate Manager 7.1 Note Before using this information and the product it supports, be sure to read the information in Notices,

More information

TFS ApplicationControl White Paper

TFS ApplicationControl White Paper White Paper Transparent, Encrypted Access to Networked Applications TFS Technology www.tfstech.com Table of Contents Overview 3 User Friendliness Saves Time 3 Enhanced Security Saves Worry 3 Software Componenets

More information

Chapter 10. Cloud Security Mechanisms

Chapter 10. Cloud Security Mechanisms Chapter 10. Cloud Security Mechanisms 10.1 Encryption 10.2 Hashing 10.3 Digital Signature 10.4 Public Key Infrastructure (PKI) 10.5 Identity and Access Management (IAM) 10.6 Single Sign-On (SSO) 10.7 Cloud-Based

More information

2.4: Authentication Authentication types Authentication schemes: RSA, Lamport s Hash Mutual Authentication Session Keys Trusted Intermediaries

2.4: Authentication Authentication types Authentication schemes: RSA, Lamport s Hash Mutual Authentication Session Keys Trusted Intermediaries Chapter 2: Security Techniques Background Secret Key Cryptography Public Key Cryptography Hash Functions Authentication Chapter 3: Security on Network and Transport Layer Chapter 4: Security on the Application

More information

Digital Certificates (Public Key Infrastructure) Reshma Afshar Indiana State University

Digital Certificates (Public Key Infrastructure) Reshma Afshar Indiana State University Digital Certificates (Public Key Infrastructure) Reshma Afshar Indiana State University October 2015 1 List of Figures Contents 1 Introduction 1 2 History 2 3 Public Key Infrastructure (PKI) 3 3.1 Certificate

More information

CA Performance Center

CA Performance Center CA Performance Center Single Sign-On User Guide 2.4 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation ) is

More information

Creating Web Services in NetBeans

Creating Web Services in NetBeans Creating Web Services in NetBeans Fulvio Frati fulvio.frati@unimi.it Sesar Lab http://ra.crema.unimi.it 1 Outline Web Services Overview Creation of a Web Services Server Creation of different Web Services

More information

A Single Sign-On Framework for Web-Services-based Distributed Applications

A Single Sign-On Framework for Web-Services-based Distributed Applications A Single Sign-On Framework for Web-Services-based Distributed Applications Markus Hillenbrand, Joachim Götze, Jochen Müller, Paul Müller University of Kaiserslautern, PO Box 3049, D-67653 Kaiserslautern,

More information

igovt logon service Context Mapping Service (icms) Messaging Specification Release 9.6

igovt logon service Context Mapping Service (icms) Messaging Specification Release 9.6 igovt logon service Context Mapping Service (icms) Messaging Specification Release 9.6 Subject Client Author Context Mapping Service Messaging Specification for the igovt logon service The Department of

More information

Authentication Types. Password-based Authentication. Off-Line Password Guessing

Authentication Types. Password-based Authentication. Off-Line Password Guessing Authentication Types Chapter 2: Security Techniques Background Secret Key Cryptography Public Key Cryptography Hash Functions Authentication Chapter 3: Security on Network and Transport Layer Chapter 4:

More information

Architecture Guidelines Application Security

Architecture Guidelines Application Security Executive Summary These guidelines describe best practice for application security for 2 or 3 tier web-based applications. It covers the use of common security mechanisms including Authentication, Authorisation

More information

OpenHRE Security Architecture. (DRAFT v0.5)

OpenHRE Security Architecture. (DRAFT v0.5) OpenHRE Security Architecture (DRAFT v0.5) Table of Contents Introduction -----------------------------------------------------------------------------------------------------------------------2 Assumptions----------------------------------------------------------------------------------------------------------------------2

More information

Sync Security and Privacy Brief

Sync Security and Privacy Brief Introduction Security and privacy are two of the leading issues for users when transferring important files. Keeping data on-premises makes business and IT leaders feel more secure, but comes with technical

More information

CHAPTER 4 DEPLOYMENT OF ESGC-PKC IN NON-COMMERCIAL E-COMMERCE APPLICATIONS

CHAPTER 4 DEPLOYMENT OF ESGC-PKC IN NON-COMMERCIAL E-COMMERCE APPLICATIONS 70 CHAPTER 4 DEPLOYMENT OF ESGC-PKC IN NON-COMMERCIAL E-COMMERCE APPLICATIONS 4.1 INTRODUCTION In this research work, a new enhanced SGC-PKC has been proposed for improving the electronic commerce and

More information

Introduction to SAML

Introduction to SAML Introduction to THE LEADER IN API AND CLOUD GATEWAY TECHNOLOGY Introduction to Introduction In today s world of rapidly expanding and growing software development; organizations, enterprises and governments

More information

vcenter Single Sign On Programming Guide vcenter Single Sign On SDK vsphere 5.5

vcenter Single Sign On Programming Guide vcenter Single Sign On SDK vsphere 5.5 vcenter Single Sign On Programming Guide vcenter Single Sign On SDK vsphere 5.5 This document supports the version of each product listed and supports all subsequent versions until the document is replaced

More information

E-Authentication Federation Adopted Schemes

E-Authentication Federation Adopted Schemes E-Authentication Federation Adopted Schemes Version 1.0.0 Final May 4, 2007 Document History Status Release Date Comment Audience Template 0.0.0 1/18/06 Outline PMO Draft 0.0.1 1/19/07 Initial draft Internal

More information

PROVIDING SINGLE SIGN-ON TO AMAZON EC2 APPLICATIONS FROM AN ON-PREMISES WINDOWS DOMAIN

PROVIDING SINGLE SIGN-ON TO AMAZON EC2 APPLICATIONS FROM AN ON-PREMISES WINDOWS DOMAIN PROVIDING SINGLE SIGN-ON TO AMAZON EC2 APPLICATIONS FROM AN ON-PREMISES WINDOWS DOMAIN CONNECTING TO THE CLOUD DAVID CHAPPELL DECEMBER 2009 SPONSORED BY AMAZON AND MICROSOFT CORPORATION CONTENTS The Challenge:

More information

Architecture. The DMZ is a portion of a network that separates a purely internal network from an external network.

Architecture. The DMZ is a portion of a network that separates a purely internal network from an external network. Architecture The policy discussed suggests that the network be partitioned into several parts with guards between the various parts to prevent information from leaking from one part to another. One part

More information

OIO SAML Profile for Identity Tokens

OIO SAML Profile for Identity Tokens > OIO SAML Profile for Identity Tokens Version 1.0 IT- & Telestyrelsen October 2009 Content > Document History 3 Introduction 4 Related profiles 4 Profile Requirements 6 Requirements 6

More information

CA Nimsoft Service Desk

CA Nimsoft Service Desk CA Nimsoft Service Desk Single Sign-On Configuration Guide 6.2.6 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation

More information

Computer Systems Security 2013/2014. Single Sign-On. Bruno Maia ei09095@fe.up.pt. Pedro Borges ei09063@fe.up.pt

Computer Systems Security 2013/2014. Single Sign-On. Bruno Maia ei09095@fe.up.pt. Pedro Borges ei09063@fe.up.pt Computer Systems Security 2013/2014 Single Sign-On Bruno Maia ei09095@fe.up.pt Pedro Borges ei09063@fe.up.pt December 13, 2013 Contents 1 Introduction 2 2 Explanation of SSO systems 2 2.1 OpenID.................................

More information

Copyright 2012, Oracle and/or its affiliates. All rights reserved.

Copyright 2012, Oracle and/or its affiliates. All rights reserved. 1 OTM and SOA Mark Hagan Principal Software Engineer Oracle Product Development Content What is SOA? What is Web Services Security? Web Services Security in OTM Futures 3 PARADIGM 4 Content What is SOA?

More information

Protecting Microsoft Internet Information Services Web Servers with ISA Server 2004

Protecting Microsoft Internet Information Services Web Servers with ISA Server 2004 Protecting Microsoft Internet Information Services Web Servers with ISA Server 2004 White Paper Published: June 2004 For the latest information, please see http://www.microsoft.com/isaserver/ Contents

More information

Flexible Identity Federation

Flexible Identity Federation Flexible Identity Federation Quick start guide version 1.0.1 Publication history Date Description Revision 2015.09.23 initial release 1.0.0 2015.12.11 minor updates 1.0.1 Copyright Orange Business Services

More information

Two SSO Architectures with a Single Set of Credentials

Two SSO Architectures with a Single Set of Credentials Two SSO Architectures with a Single Set of Credentials Abstract Single sign-on (SSO) is a widely used mechanism that uses a single action of authentication and authority to permit an authorized user to

More information

GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK

GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK Antti Pyykkö, Mikko Malinen, Oskari Miettinen GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK TJTSE54 Assignment 29.4.2008 Jyväskylä University Department of Computer Science

More information

CICS Web Service Security. Anthony Papageorgiou IBM CICS Development March 13, 2012 Session: 10282

CICS Web Service Security. Anthony Papageorgiou IBM CICS Development March 13, 2012 Session: 10282 Web Service Security Anthony Papageorgiou IBM Development March 13, 2012 Session: 10282 Agenda Web Service Support Overview Security Basics and Terminology Pipeline Security Overview Identity Encryption

More information

Copyright: WhosOnLocation Limited

Copyright: WhosOnLocation Limited How SSO Works in WhosOnLocation About Single Sign-on By default, your administrators and users are authenticated and logged in using WhosOnLocation s user authentication. You can however bypass this and

More information

Certification Practice Statement

Certification Practice Statement FernUniversität in Hagen: Certification Authority (CA) Certification Practice Statement VERSION 1.1 Ralph Knoche 18.12.2009 Contents 1. Introduction... 4 1.1. Overview... 4 1.2. Scope of the Certification

More information

Java Security Web Services Security (Overview) Lecture 9

Java Security Web Services Security (Overview) Lecture 9 Java Security Web Services Security (Overview) Lecture 9 Java 2 Cryptography Java provides API + SPI for crypto functions Java Cryptography Architecture Security related core classes Access control and

More information

Enabling Federation and Web-Single Sign-On in Heterogeneous Landscapes with the Identity Provider and Security Token Service Supplied by SAP NetWeaver

Enabling Federation and Web-Single Sign-On in Heterogeneous Landscapes with the Identity Provider and Security Token Service Supplied by SAP NetWeaver Enabling Federation and Web-Single Sign-On in Heterogeneous Landscapes with the Identity Provider and Security Token Service Supplied by SAP NetWeaver SAP Product Management, SAP NetWeaver Identity Management

More information

IVOA Single-Sign-On Profile: Authentication Mechanisms Version 2.0

IVOA Single-Sign-On Profile: Authentication Mechanisms Version 2.0 International Virtual Observatory Alliance IVOA Single-Sign-On Profile: Authentication Mechanisms Version 2.0 IVOA Proposed Recommendation 20151029 Working group http://www.ivoa.net/twiki/bin/view/ivoa/ivoagridandwebservices

More information

NIST s Guide to Secure Web Services

NIST s Guide to Secure Web Services NIST s Guide to Secure Web Services Presented by Gaspar Modelo-Howard and Ratsameetip Wita Secure and Dependable Web Services National Institute of Standards and Technology. Special Publication 800-95:

More information

Introduction to Service Oriented Architectures (SOA)

Introduction to Service Oriented Architectures (SOA) Introduction to Service Oriented Architectures (SOA) Responsible Institutions: ETHZ (Concept) ETHZ (Overall) ETHZ (Revision) http://www.eu-orchestra.org - Version from: 26.10.2007 1 Content 1. Introduction

More information

Integration of Hotel Property Management Systems (HPMS) with Global Internet Reservation Systems

Integration of Hotel Property Management Systems (HPMS) with Global Internet Reservation Systems Integration of Hotel Property Management Systems (HPMS) with Global Internet Reservation Systems If company want to be competitive on global market nowadays, it have to be persistent on Internet. If we

More information

Allidm.com. SSO Introduction. Discovering IAM Solutions. Leading the IAM Training. @aidy_idm facebook/allidm

Allidm.com. SSO Introduction. Discovering IAM Solutions. Leading the IAM Training. @aidy_idm facebook/allidm Discovering IAM Solutions Leading the IAM Training @aidy_idm facebook/allidm SSO Introduction Disclaimer and Acknowledgments The contents here are created as a own personal endeavor and thus does not reflect

More information

Evaluation of different Open Source Identity management Systems

Evaluation of different Open Source Identity management Systems Evaluation of different Open Source Identity management Systems Ghasan Bhatti, Syed Yasir Imtiaz Linkoping s universitetet, Sweden [ghabh683, syeim642]@student.liu.se 1. Abstract Identity management systems

More information

Security and Reliability for Web Services

Security and Reliability for Web Services Security and Reliability for Web Services v Takayuki Maeda v Yoshihide Nomura v Hirotaka Hara (Manuscript received June 22, 2003) Web services are expected to become an important information technology

More information

THE BCS PROFESSIONAL EXAMINATIONS BCS Level 6 Professional Graduate Diploma in IT. April 2009 EXAMINERS' REPORT. Network Information Systems

THE BCS PROFESSIONAL EXAMINATIONS BCS Level 6 Professional Graduate Diploma in IT. April 2009 EXAMINERS' REPORT. Network Information Systems THE BCS PROFESSIONAL EXAMINATIONS BCS Level 6 Professional Graduate Diploma in IT April 2009 EXAMINERS' REPORT Network Information Systems General Comments Last year examiners report a good pass rate with

More information

Federated Identity Management Solutions

Federated Identity Management Solutions Federated Identity Management Solutions Jyri Kallela Helsinki University of Technology jkallela@cc.hut.fi Abstract Federated identity management allows users to access multiple services based on a single

More information

Network Security Protocols

Network Security Protocols Network Security Protocols EE657 Parallel Processing Fall 2000 Peachawat Peachavanish Level of Implementation Internet Layer Security Ex. IP Security Protocol (IPSEC) Host-to-Host Basis, No Packets Discrimination

More information

Information Security

Information Security Information Security Dr. Vedat Coşkun Malardalen September 15th, 2009 08:00 10:00 vedatcoskun@isikun.edu.tr www.isikun.edu.tr/~vedatcoskun What needs to be secured? With the rapid advances in networked

More information

XML Signatures in an Enterprise Service Bus Environment

XML Signatures in an Enterprise Service Bus Environment XML Signatures in an Enterprise Bus Environment Eckehard Hermann Research & Development XML Integration Uhlandstraße 12 64297 Darmstadt, Germany Eckehard.Hermann@softwareag.com Dieter Kessler Research

More information

National Identity Exchange Federation (NIEF) Trustmark Signing Certificate Policy. Version 1.1. February 2, 2016

National Identity Exchange Federation (NIEF) Trustmark Signing Certificate Policy. Version 1.1. February 2, 2016 National Identity Exchange Federation (NIEF) Trustmark Signing Certificate Policy Version 1.1 February 2, 2016 Copyright 2016, Georgia Tech Research Institute Table of Contents TABLE OF CONTENTS I 1 INTRODUCTION

More information

Service Virtualization: Managing Change in a Service-Oriented Architecture

Service Virtualization: Managing Change in a Service-Oriented Architecture Service Virtualization: Managing Change in a Service-Oriented Architecture Abstract Load balancers, name servers (for example, Domain Name System [DNS]), and stock brokerage services are examples of virtual

More information

Leverage Active Directory with Kerberos to Eliminate HTTP Password

Leverage Active Directory with Kerberos to Eliminate HTTP Password Leverage Active Directory with Kerberos to Eliminate HTTP Password PistolStar, Inc. PO Box 1226 Amherst, NH 03031 USA Phone: 603.547.1200 Fax: 603.546.2309 E-mail: salesteam@pistolstar.com Website: www.pistolstar.com

More information

Authentication and Single Sign On

Authentication and Single Sign On Contents 1. Introduction 2. Fronter Authentication 2.1 Passwords in Fronter 2.2 Secure Sockets Layer 2.3 Fronter remote authentication 3. External authentication through remote LDAP 3.1 Regular LDAP authentication

More information

WHITE PAPER. Smart Card Authentication for J2EE Applications Using Vintela SSO for Java (VSJ)

WHITE PAPER. Smart Card Authentication for J2EE Applications Using Vintela SSO for Java (VSJ) WHITE PAPER Smart Card Authentication for J2EE Applications Using Vintela SSO for Java (VSJ) SEPTEMBER 2004 Overview Password-based authentication is weak and smart cards offer a way to address this weakness,

More information

Federated Identity Architectures

Federated Identity Architectures Federated Identity Architectures Uciel Fragoso-Rodriguez Instituto Tecnológico Autónomo de México, México {uciel@itam.mx} Maryline Laurent-Maknavicius CNRS Samovar UMR 5157, GET Institut National des Télécommunications,

More information

Getting Started with AD/LDAP SSO

Getting Started with AD/LDAP SSO Getting Started with AD/LDAP SSO Active Directory and LDAP single sign- on (SSO) with Syncplicity Business Edition accounts allows companies of any size to leverage their existing corporate directories

More information

A Federated Authorization and Authentication Infrastructure for Unified Single Sign On

A Federated Authorization and Authentication Infrastructure for Unified Single Sign On A Federated Authorization and Authentication Infrastructure for Unified Single Sign On Sascha Neinert Computing Centre University of Stuttgart Allmandring 30a 70550 Stuttgart sascha.neinert@rus.uni-stuttgart.de

More information

Web Services Security with SOAP Security Proxies

Web Services Security with SOAP Security Proxies Web Services Security with Security Proxies Gerald Brose, PhD Technical Product Manager Xtradyne Technologies AG OMG Web Services Workshop USA 22 April 2003, Philadelphia Web Services Security Risks! Exposure

More information

The Essentials Series: Enterprise Identity and Access Management. Authentication. sponsored by. by Richard Siddaway

The Essentials Series: Enterprise Identity and Access Management. Authentication. sponsored by. by Richard Siddaway The Essentials Series: Enterprise Identity and Access Management Authentication sponsored by by Richard Siddaway Authentication...1 Issues in Authentication...1 Passwords The Weakest Link?...2 Privileged

More information

SAML-Based SSO Solution

SAML-Based SSO Solution About SAML SSO Solution, page 1 SAML-Based SSO Features, page 2 Basic Elements of a SAML SSO Solution, page 2 SAML SSO Web Browsers, page 3 Cisco Unified Communications Applications that Support SAML SSO,

More information

Authentication Application

Authentication Application Authentication Application KERBEROS In an open distributed environment servers to be able to restrict access to authorized users to be able to authenticate requests for service a workstation cannot be

More information

Device-Centric Authentication and WebCrypto

Device-Centric Authentication and WebCrypto Device-Centric Authentication and WebCrypto Dirk Balfanz, Google, balfanz@google.com A Position Paper for the W3C Workshop on Web Cryptography Next Steps Device-Centric Authentication We believe that the

More information

Authentication Integration

Authentication Integration Authentication Integration VoiceThread provides multiple authentication frameworks allowing your organization to choose the optimal method to implement. This document details the various available authentication

More information

Authentication is not Authorization?! And what is a "digital signature" anyway?

Authentication is not Authorization?! And what is a digital signature anyway? Authentication is not Authorization?! And what is a "digital signature" anyway? Prepared by R. David Vernon Revised 12/01 Introduction REV 1A As part of the IT Architecture Initiative, the Office of Information

More information

Single Sign-On Implementation Guide

Single Sign-On Implementation Guide Salesforce.com: Salesforce Winter '09 Single Sign-On Implementation Guide Copyright 2000-2008 salesforce.com, inc. All rights reserved. Salesforce.com and the no software logo are registered trademarks,

More information

IT@Intel. Improving Security and Productivity through Federation and Single Sign-on

IT@Intel. Improving Security and Productivity through Federation and Single Sign-on White Paper Intel Information Technology Computer Manufacturing Security Improving Security and Productivity through Federation and Single Sign-on Intel IT has developed a strategy and process for providing

More information

Digital Identity and Identity Management Technologies.

Digital Identity and Identity Management Technologies. I. Agudo, Digital Identity and Identity Management Technologies, UPGRADE - The European Journal of the Informatics Professional, vol. 2010, pp. 6-12, 2010. NICS Lab. Publications: https://www.nics.uma.es/publications

More information

Single Sign-on (SSO) technologies for the Domino Web Server

Single Sign-on (SSO) technologies for the Domino Web Server Single Sign-on (SSO) technologies for the Domino Web Server Jane Marcus December 7, 2011 2011 IBM Corporation Welcome Participant Passcode: 4297643 2011 IBM Corporation 2 Agenda USA Toll Free (866) 803-2145

More information

Secure Identity Propagation Using WS- Trust, SAML2, and WS-Security 12 Apr 2011 IBM Impact

Secure Identity Propagation Using WS- Trust, SAML2, and WS-Security 12 Apr 2011 IBM Impact Secure Identity Propagation Using WS- Trust, SAML2, and WS-Security 12 Apr 2011 IBM Impact Robert C. Broeckelmann Jr., Enterprise Middleware Architect Ryan Triplett, Middleware Security Architect Requirements

More information

IBM i Version 7.2. Security Single sign-on

IBM i Version 7.2. Security Single sign-on IBM i Version 7.2 Security Single sign-on IBM i Version 7.2 Security Single sign-on Note Before using this information and the product it supports, read the information in Notices on page 83. This edition

More information

A Model for Access Control Management in Distributed Networks

A Model for Access Control Management in Distributed Networks A Model for Access Control Management in Distributed Networks Master of Science Thesis Azadeh Bararsani Supervisor/Examiner: Dr. Johan Montelius Royal Institute of Technology (KTH), Stockholm, Sweden,

More information

GT 6.0 GSI C Security: Key Concepts

GT 6.0 GSI C Security: Key Concepts GT 6.0 GSI C Security: Key Concepts GT 6.0 GSI C Security: Key Concepts Overview GSI uses public key cryptography (also known as asymmetric cryptography) as the basis for its functionality. Many of the

More information

Chapter 15 User Authentication

Chapter 15 User Authentication Chapter 15 User Authentication 2015. 04. 06 Jae Woong Joo SeoulTech (woong07@seoultech.ac.kr) Table of Contents 15.1 Remote User-Authentication Principles 15.2 Remote User-Authentication Using Symmetric

More information

Setup Guide Access Manager Appliance 3.2 SP3

Setup Guide Access Manager Appliance 3.2 SP3 Setup Guide Access Manager Appliance 3.2 SP3 August 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS

More information

STUDY ON IMPROVING WEB SECURITY USING SAML TOKEN

STUDY ON IMPROVING WEB SECURITY USING SAML TOKEN STUDY ON IMPROVING WEB SECURITY USING SAML TOKEN 1 Venkadesh.M M.tech, Dr.A.Chandra Sekar M.E., Ph.d MISTE 2 1 ResearchScholar, Bharath University, Chennai 73, India. venkadeshkumaresan@yahoo.co.in 2 Professor-CSC

More information

Information Security Basic Concepts

Information Security Basic Concepts Information Security Basic Concepts 1 What is security in general Security is about protecting assets from damage or harm Focuses on all types of assets Example: your body, possessions, the environment,

More information

Security+ Guide to Network Security Fundamentals, Third Edition. Chapter 12 Applying Cryptography

Security+ Guide to Network Security Fundamentals, Third Edition. Chapter 12 Applying Cryptography Security+ Guide to Network Security Fundamentals, Third Edition Chapter 12 Applying Cryptography Objectives Define digital certificates List the various types of digital certificates and how they are used

More information

Secure Client Applications

Secure Client Applications Secure Client Applications Networking Sirindhorn International Institute of Technology Thammasat University Prepared by Steven Gordon on 26 June 2014 Common/Reports/secure-client-apps.tex, r900 1/26 Acronyms

More information

Web Applications Access Control Single Sign On

Web Applications Access Control Single Sign On Web Applications Access Control Single Sign On Anitha Chepuru, Assocaite Professor IT Dept, G.Narayanamma Institute of Technology and Science (for women), Shaikpet, Hyderabad - 500008, Andhra Pradesh,

More information

SAML Security Option White Paper

SAML Security Option White Paper Fujitsu mpollux SAML Security Option White Paper Fujitsu mpollux Version 2.1 February 2009 First Edition February 2009 The programs described in this document may only be used in accordance with the conditions

More information

Lukasz Pater CMMS Administrator and Developer

Lukasz Pater CMMS Administrator and Developer Lukasz Pater CMMS Administrator and Developer EDMS 1373428 Agenda Introduction Why do we need asymmetric ciphers? One-way functions RSA Cipher Message Integrity Examples Secure Socket Layer Single Sign

More information

Enterprise SSO Manager (E-SSO-M)

Enterprise SSO Manager (E-SSO-M) Enterprise SSO Manager (E-SSO-M) Many resources, such as internet applications, internal network applications and Operating Systems, require the end user to log in several times before they are empowered

More information

OIOIDWS for Healthcare Token Profile for Authentication Tokens

OIOIDWS for Healthcare Token Profile for Authentication Tokens OIOIDWS for Healthcare Token Profile for Authentication Tokens Common Web Service Profile for Healthcare in the Danish Public Sector, version 2.0 Content Document History...3 Introduction...4 Notation...

More information

Web Services Security: What s Required To Secure A Service-Oriented Architecture. An Oracle White Paper January 2008

Web Services Security: What s Required To Secure A Service-Oriented Architecture. An Oracle White Paper January 2008 Web Services Security: What s Required To Secure A Service-Oriented Architecture An Oracle White Paper January 2008 Web Services Security: What s Required To Secure A Service-Oriented Architecture. INTRODUCTION

More information

Chapter 6 Electronic Mail Security

Chapter 6 Electronic Mail Security Cryptography and Network Security Chapter 6 Electronic Mail Security Lectured by Nguyễn Đức Thái Outline Pretty Good Privacy S/MIME 2 Electronic Mail Security In virtually all distributed environments,

More information

New Single Sign-on Options for IBM Lotus Notes & Domino. 2012 IBM Corporation

New Single Sign-on Options for IBM Lotus Notes & Domino. 2012 IBM Corporation New Single Sign-on Options for IBM Lotus Notes & Domino 2012 IBM Corporation IBM s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM s sole

More information

A Federated Model for Secure Web-Based Videoconferencing

A Federated Model for Secure Web-Based Videoconferencing A Federated Model for Secure Web-Based Videoconferencing Douglas C. Sicker, Ameet Kulkarni, Anand Chavali, and Mudassir Fajandar Interdisciplinary Telecommunications Dept. and Dept. of Computer Science

More information

Public Key Applications & Usage A Brief Insight

Public Key Applications & Usage A Brief Insight Public Key Applications & Usage A Brief Insight Scenario :: Identification, Authentication & Non- Repudiation :: Confidentiality :: Authenticity, requirements and e-business Integrity for electronic transaction

More information

Setup Guide Access Manager 3.2 SP3

Setup Guide Access Manager 3.2 SP3 Setup Guide Access Manager 3.2 SP3 August 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE

More information

HTTP State Management

HTTP State Management HTTP State Management Candidate Version 1.1 27 Feb 2007 Open Mobile Alliance OMA-TS-HTTPSM-V1_1-20070227-C OMA-TS-HTTPSM-V1_1-20070227-C Page 2 (17) Use of this document is subject to all of the terms

More information

Using SAP Logon Tickets for Single Sign on to Microsoft based web applications

Using SAP Logon Tickets for Single Sign on to Microsoft based web applications Collaboration Technology Support Center - Microsoft - Collaboration Brief March 2005 Using SAP Logon Tickets for Single Sign on to Microsoft based web applications André Fischer, Project Manager CTSC,

More information

The BritNed Explicit Auction Management System. Kingdom Web Services Interfaces

The BritNed Explicit Auction Management System. Kingdom Web Services Interfaces The BritNed Explicit Auction Management System Kingdom Web Services Interfaces Version 5.1 November 2014 Contents 1. PREFACE... 6 1.1. Purpose of the Document... 6 1.2. Document Organization... 6 2. Web

More information

Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified

Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified Standard: Data Security Standard (DSS) Requirement: 6.6 Date: February 2008 Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified Release date: 2008-04-15 General PCI

More information