IdM systems involve at least two types of entity, namely Identity Providers .... The first type, that we refer to as trust ticket, encodes the list of federation service.
Integrating Federated Digital Identity Management and Trust Negotiation– issues and solutions Abhilasha Bhargav-Spantzel
Anna C. Squicciarini
Elisa Bertino
CERIAS and Department of Computer Science, Purdue University (bhargav,squiccia,bertino)@cs.purdue.edu
Abstract Most organizations today require the verification of personal information pertaining to users in order to provide service to users. Privacy of such information is of growing concern and because organizations often ask for similar information, this process can also be redundant and inefficient. Recent proposals dealing with federated identity management have the potential to alleviate such problems. The trust negotiation paradigm has several similarities with federated identity management as they both aim at better handling users’ sensitive information. It is thus important to clearly assess their differences and their similarities in order to better understand the potential advantages deriving from their integration. In this paper we develop such a comparison according to a number of relevant criteria, and we review the most well known initiatives and projects. Based on such an analysis we discuss how to integrate federated IdM with trust negotiation techniques, such as those provided as part of the Trust-χ [3] system. More specifically, we discuss how to implement trust negotiation between service providers in a federation, and between users and service providers. This is, to the best of our knowledge, the first attempt to integrate a federated IdM management system with a trust negotiation system.
Keywords: Federated identity management, trust negotiation, access control, security and privacy
1 Introduction In today’s increasing competitive business environment, more and more leading organizations are building web-based infrastructures to gain the strategic advantages of collaborative networking. However, to facilitate collaboration and to fully exploit such infrastructures, organizations need to identify each user in the collaborative network and which resources each user is authorized to access. User identification and access control must however be carried out so to maximize user convenience and privacy assurance, and at the same time without increasing the operational costs for organizations. The concept of federation has been proposed as the basic context with respect to which suitable solutions to such issue can be developed. A federation can be considered as a set of organizations which establish trust relationships with respect to which certain identity information, referred to as federated identity information, is considered valid. A federated identity management system (IdM) provides a group of organizations, which have collaborations or business agreements, with mechanisms for managing and gaining access to user identity information and other resources across organizational boundaries. The main functions of an IdM system are creation, storage and access of user digital identities and profiles. IdM systems involve at least two types of entity, namely Identity Providers (IdP) and Service Providers (SP). A SP is an entity offering services to users, provided that users satisfy the policy requirements associated with these services. An IdP is an entity in charge of user authentication and of managing all identity relevant information concerning users. An SP, on the other hand, is responsible for the specification and enforcement of the access control policies for the resources it offers. When SPs initially require identity information from users for the purpose of access control, they should inform the users about their data practices especially for 1
secondary usage of the data. It is important to note that the same organization in a federation can act both as a IdP and SP but because of the difference in functionality it is useful to make a logical distinction. In most common IdM systems [13, 12] IdP’s authenticate users by means of single-sign-on (SSO) technology. With SSO users can use the same username and password for a seamless access to federated services, within one or multiple organizations. The notion of federated identity has been recently extended to include not only user’s login names, but also user properties, also referred to as user identity attributes (user attributes, for short). Such an extension has been motivated by the fact that in an increasing number of applications access control policies are based on security-relevant properties of users. Thus authorizations specified for a given resource are not any longer expressed in terms of user login ids. Rather, they are expressed in terms of requirements and conditions against user properties. One challenge with current IdM systems is to distribute the functionality of the IdP among different IdP’s and SP’s 1 . We need a secure and privacy preserving mechanism for retrieving the user attributes from different SP’s. We need approaches that provide only the user’s information which are strictly needed to satisfy the access control policies of the requesting SP’s. If not, the privacy of the user attributes may be vulnerable as they would reside in multiple locations within a federation, some of which might not be trusted by the user. In this respect it is also important to notice that, as shown by a recent survey [1], users have differentiated privacy preferences with respect to the various types of information concerning themselves. For example users may agree to share demographic information with organizations but not credit card or health information. Such requirements call for a flexible and selective approach to the problem of sharing user attributes in federations. One way to achieve selective release of identity is to support multiple federated digital identities. For example, a user could have a business identity and a personal identity, the profiles corresponding to which would have associated different privacy preferences. Such an approach, however, is not desirable since it contradicts the main aim of federated identity solutions. One approach to achieve such flexibility and fine grained access is to enhance IdM technology with automated trust negotiation (ATN) techniques [3, 17]. Trust negotiation is an emerging access control approach for establishing trust in open systems, like the Internet. The idea of trust negotiation is to establish trust on line between (generally) two negotiating parties through bilateral credential disclosure. Digital credentials are assertions stating one or more properties about a given subject, referred to as the “owner”, certified by trusted third parties. The goal of such a negotiation is to establish a sufficient level of trust so that sensitive resources, which may be either data or services, can be safely released. A key aspect of trust negotiation is that credentials themselves are often considered sensitive by credential holders, and thus may need to be protected by their own disclosure policies. Disclosure policies state the conditions under which a resource can be released during a negotiation. Conditions are usually expressed as constraints against the credentials possessed by the interacting parties and their properties. To carry out a trust negotiation, parties usually adopt a strategy, which is implemented by an algorithm defining which credentials to disclose, when to disclose them and whether to succeed or fail the negotiation. There are a number of strategies for negotiating trust, each with different properties with respect to speed of negotiations and caution in releasing credentials and policies. As digital identity management systems and trust negotiation systems are two technologies with many common goals, it is important to clearly assess their differences and their similarities in order to better understand the potential advantages deriving from their integration. In this paper we develop such a comparison according to a number of relevant criteria, and we review the most well known initiatives and projects. Based on such an analysis we discuss how to integrate federated IdM with trust negotiation techniques, such as those provided as part of the Trust-χ [3] system. More specifically, we discuss how to implement trust negotiation between service providers in a federation, and between users and service providers. This is, to the best of our knowledge, the first attempt to integrate a federated IdM management system with a trust negotiation system. A key aspect of the resulting framework, referred to as FAMTN2, is that the user does not have to provide a federated 1 2
In this paper we do not differentiate between service providers and organizations in a federation. Federated Attribute Management and Trust Negotiation.
2
attribute3 more than once to a given federation. Internal users of a FAMTN system are able to perform negotiations by exploiting their SSO id without having to repeat any identity verification process. Further, a FAMTN system supports temporary SSO, so that external users can perform different negotiations with the federation by taking advantages of the federated framework to reduce the amount of of identity information they need to provide during their interactions with the federation. Our federated trust negotiation approach relies on the use of special-purpose tickets, that is, signed assertions that are released by the federation members to users upon successful negotiations. We propose two different types of ticket. The first type, that we refer to as trust ticket, encodes the list of federation service providers with which a non-member user has successfully negotiated. The second type, that we refer to as session ticket, is used by member users in order to speed up negotiations. We take advantage of the fact that most attributes do not change in a short period of time; thus if a user recently received a service, she is most likely eligible for the service again. We also propose a possible implementation of trust tickets through cookies. Cookies support some use functions, such as redirection for seamless access to federated sites. However, currently cookies suffer of many security problems as they are generally unprotected in client machines possibly accessed by multiple users. To overcome some of the security problems related to cookies usage, we motivate the need for a language for fine grained selective access for cookies which is supported by trust negotiation protocols. The rest of the paper is organized as follows. Section 2 presents a detailed comparison of trust negotiation and federated identity management systems followed by a survey of existing proposals in the two fields. Section 3 discusses the integration among these two types of system and presents our proposed framework. Section 4 discusses the ticketing and negotiation process in the proposed framework. We then conclude in Section 5 by outlining future work.
2 A Survey of Identity Management and Trust Negotiation In this section we survey IdM and ATN systems, by first comparing the two technologies against a number of relevant criteria. We then present an overview of the most relevant initiatives and projects currently available.
2.1 Automated Trust Negotiation and Digital Identity Management Systems–Differences and Similarities The trust negotiation paradigm has several similarities with federated identity management. It has been argued that the two models might substitute one another as they both aim at better handling users’ sensitive information. However, trust negotiation’s ultimate goal is to handle introductions between strangers, while identity management systems have been designed for closed environments. Besides this simple consideration, there are several other aspects in which they differ which are illustrated in what follows. 1. Open vs. Closed Environment. ATN techniques [6] have been developed for use in open systems and aim at providing protocols for stranger introduction to each other. This is in contrast to identity management frameworks which are typically in closed systems. ATN work suggests that the techniques may be useful for the initial trust establishment process between users and IdP’s or to automatically manage introductions between different federation groups. 2. Credential and Identity Attribute Management. In a typical ATN system the IdP is the user herself. ATN is a user centric system where the credentials are stored and provided by a client on behalf of a user with the help of negotiation. Although there has been recent work on storing user credentials with SP’s using anonymous credentials, the majority of ATN systems assume that users directly manage their own 3
Attributes the user is willing to share in a federation are called federated attributes.
3
Criteria Environment Credential Management Attributes Used Attribute Encoding
Architecture Policies Policy Language Trust Model Unique Identification Credential discovery
ATN Systems Open Environment User Centric Certified Attributes or Credentials X.509 certificates, XML certificates P2P Privacy Policies, Access Control Policies X-TNL, RT, PROTUNE etc. Pairwise Trust (some brokered trust) Optional Credential chain management protocols
IdM Systems Closed Environment Poly Centric Certified and uncertified Attributes username, SAML assertions, X.509 certificates, Kerberos Tickets Client Server Privacy Policies, Authorization Policies XACML Pairwise Trust, Brokered Trust, Community Trust SSO required Discovery Service protocols
Table 1: Comparison of ATN and IdM systems credentials. In IdM systems, on the other hand, the AP’s saves the user profiles for future use in the federation according to the privacy preferences of the owner of the profile which is the user herself. Regarding attribute certification, ATN’s typically negotiate certified attributes or credentials. In IdM systems uncertified attributes are mainly used, although certified attributes can also be supported. IdM systems usually rely on SAML assertions for the encoding of the attributes, whereas in ATN systems attributes are encoded in credentials, which are digital certificate equivalent of physical certificates, represented according to the X.509 certificate format or alike. 3. Architectural differences. An ATN system is typically used in peer-to-peer (P2P) systems. This means that the basic architecture of clients and SP’s is identical. Any entity playing the role of provider in a trust negotiation can act as a client in different negotiations, if needed. In this respect ATN systems differ to a great extent with respect to IdM frameworks in which IdP, SP and clients all have different architectural components depending on the functionality of that entity. Due to the P2P nature of ATN systems, the integration of an ATN architectural components becomes simpler with the existing IdM systems. This aspect is further illustrated later in the paper. 4. Policies. In both IdM and ATN systems one of the goals is to satisfy user privacy preferences for their personal data and to make sure that access control policies are stated and enforced. Therefore both types of system have privacy and access control policies. However, in ATN systems access control policies play a key role in the trust negotiation processes, whereas they are only a a marginal aspect in the IdM systems. As such, ATN policies can be more complex and provide various alternative ways of satisfying the requirements for access to a given resource or expressing different usage conditions. This ensures soundness for any transaction, meaning that if user preferences and the SP’s requirements are compatible then the transaction will certainly succeed. Soundness is not guaranteed in current IdM systems because of the lack of formal negotiation procedures and a corresponding expressive policy languages. IdM systems however provide mechanisms for policy exchange which could be used by additional negotiation modules in order to provide ATN functions. 5. User Identity. Both ATN and IdM systems require users to be identified. Such requirement is particularly relevant in IdM systems, which actually aim at uniquely identifying users within federations. Every user 4
in an IdM needs a SSO to interact with any SP in the federation and attributes of the user herself to be linked to her. By contrast, identity is usually a secondary aspect in ATN systems as authentication is mainly based on properties of the user rather than on the sole identity. However, real case scenarios show that authentication is often a first class requirement in specific negotiations. A further aspect to highlight is that IdM systems rely on SSO to identify users; there is therefore no need to certify user identities in other ways. In ATN systems, instead, identification is obtained by credentials combinations although SSO might be employed in specific contexts. In these systems there is no need to link multiple negotiations to the same identity as identification is (if required) executed on the fly, while the negotiation process is taking place. 6. Trust Model. There are three main types of trust models in a typical IdM system [8], namely pairwise, brokered and community trust model. The pairwise model is related to the case where two entities have direct business agreements with each other. Brokered trust model is related to the case of two entities that do not have a direct agreement with each other, but have some agreements with one or more intermediaries so as to enable a business trust path to be constructed between the two entities. Although all three trust models can use ATN systems we found that with the brokered trust model integrated with ATN is particularly interesting, since it provides a unique feature to existing IdM systems. Besides the aspects discussed above, there are many other common aspects between IdM and ATN systems, even though with some differences. For instance, a relevant aspect is related to credential discovery, which is required in both the environments, although in a different manner. Using the Discovery Service mentioned earlier the IdM’s collaborate in order to be able to make assertions about a user from a local IdP to a remote IdP. Similarly, in ATN systems, credential discovery is extensively used to retrieve remote credentials not available at the negotiating parties. Another related aspect is delegation. Although this is not a main issue in trust negotiations, delegation is achieved through ad-hoc protocols and credentials enabling entities to negotiate in behalf of third parties. In IdM systems we can use the brokered trust model, discussed earlier, to delegate the responsibility for attribute assertion to another IdP which the user may trust more. Table 1 summarizes the discussion. It is however important to note that our analysis is based on the pure IdM and TN models as they were originally designed. Variations to both approaches have been proposed in the last few years, which make the evaluation results slightly different.
2.2 Initiatives and Systems Federated identity management and trust negotiation have both been investigated extensively. The former is currently a business initiative of interest to several companies. In this section we elaborate on the most relevant projects. In the corporate world there are several emerging standards for identity federation like Liberty Alliance and WS-Federation. Since the projects are very similar we describe the former in more detail below. Liberty Alliance [12] is based on SAML4 and provides open standards for single sign-on (SSO) with decentralized authentication. SSO allows a user to sign-on once at a Liberty-enabled site and to be seamlessly signed-on when navigating to another Liberty-enabled site without the need to authenticate again. This group of Libertyenabled sites is a part of what is called a circle of trust, which is a federation of SP’s and IdP’s based on Liberty architecture. The IdP is a Liberty-enabled entity that creates, maintains and manages identity information of users and provides SP’s with this information. Similarly, the FAMTN framework builds on a SSO and, in addition, it provides a flexible decentralized trust management system for registered users. According to the Liberty Alliance framework there may be multiple IdP’s in a federation and they could possibly also be SP’s. Basically, in a given Liberty circle of trust, a user can use multiple IdP’s that share his information among them. Trust relationships and access policies between these IdP’s are established a priori 4
Security Assertion Markup Language (SAML).
5
while forming the circle of trust itself. The underlying semantics and related protocols are not dictated by the Liberty protocols. Our belief is that for a truly decentralized identity management we need a more automatic methodology for federating user information among the IdP’s. In the FAMTN framework, indeed, we do not distinguish between SP’s and IdP’s: each SP in the federation can act as an IdP. The information between SP’s is simply exchanged through automatic trust negotiation, according to an on-demand dynamic protocol. Shibboleth [13] is an initiative originated in academia and is similar to the Liberty Alliance in that its goal is to facilitate sharing of resources between research and academic institutions. It extends the concept of federated identity information to federated user attributes. When a user at an institution tries to use a resource at another, Shibboleth sends attributes about the user to the remote institution, rather than making the user log in to that institution. The receiver can check whether the attributes satisfy the SP’s policy. The IdP in the Shibboleth architecture has all the user attributes and user privacy preferences which are taken into account when this IdP gives information to other SP’s. The approach of FATM differs with respect to Shibboleth in that we do not rely on a central IdP providing all user attributes. User attributes in our framework are distributed within the different SP’s in the federation, each of which can effectively be an IdP. The ability to negotiate with different SP’s adds flexibility to the way a user can define different privacy preferences with respect to different members of the federation which is not possible in Shibboleth. Shibboleth requires trust agreements to define the population, retention, and use of attributes, thus making difficult for external users (who are not affiliated with the federation) to carry on ad-hoc negotiations for using the various services offered. In other words, Shibboleth is not open to external users. In our framework, by contrast, external users can easily negotiate within the federation, because of the ad-hoc type of negotiation we provide. There are several benefits to federated identity management systems. Federated identity can deliver several compelling benefits to organizations. Federation provides means for local identities and their associated data stay in place, yet linked together through higher-level mechanisms. Table 2 in the appendix provides a survey of some existing examples of federations. Concerning trust negotiation, researchers have investigated trust negotiations for web-based applications and have developed a number of systems and prototypes [4, 2, 5, 18, 20, 21]. T rustBuilder [21] is one of the most significant proposals. It provides a set of negotiation protocols that define the ordering of messages and the type of information the messages will contain, and strategies for controlling the exact content of messages. A variety of strategies are defined to allow strangers to establish trust through the exchange of digital credentials and the use of access control policies that specify the combinations of credentials a stranger must disclose in order to gain access to each local service or credential. Winslett et al. [20] have developed Unipro, that is a unified scheme to model resource protection, including policies. It currently represents one of the most significant proposals in the negotiation research area, and it is the approach that has most greatly influenced our work. However, such approach does not deal with the support of privacy policies, nor it defines an ad hoc policy language. Seamons et al. [15] have explored the issue of supporting sensitive policies, obtained by the introduction of hierarchies in policy definitions. Further, they have also addressed privacy issues in trust negotiation [16]. However, their approach does not provide a comprehensive solution to such problems, in that it only deals with protection of sensitive policies, achieved by the introduction of dynamic policies (policies dynamically modified during a negotiation by the trust negotiation system). Li et. al. [19] introduced a role-based trust management language RT0 , which can be used to map entities to roles based on the properties described in their credentials. They have also developed an algorithm to locate and retrieve credentials that are not locally available. This aspect, known as credential chain discovery, is an important aspect of trust negotiation, since assuming the credentials to be locally stored is an assumption too strong in decentralized collaborative environments. The trust negotiation system on which our framework is based is Trust-χ [3], a trust negotiation system specifically conceived for peer to peer environments. Trust-χ is complemented by an ad-hoc XML based language χ-TNL, to encode negotiation policies, digital credentials and security related information. A main difference between Trust-χ and the current work is that the negotiation process of FAMTN is much more articulated than 6
Figure 1: External user negotiating with two SP’s of a federation. the one of Trust-χ and may involve third parties, in addition to the two parties that have initiated the negotiation. We can thus say that FAMTN is characterized by multi-party negotiations, whereas Trust-χ only supports two-party negotiations. ATN systems have been widely studied in theory and are now ready to be actually used for real applications. The TrustBuilder system [21] is an example of an actual system for support of trust negotiations. Currently, web services only provide basic negotiation capabilities. We believe that the full potential of trust negotiations will be achieved once the practical limitations related with PKI infrastructures will be overcome.
3 Integrating Identity Management and Trust Negotiations To combine the advantages of the IDM and ATN approaches, we propose a Federated Attribute Management and Trust Negotiation FAMTN solution, which provides a truly distributed approach to the management of user identities and user attributes with negotiation capabilities. A FAMTN federation essentially involves two type of entities: FAMTN service providers (FSP) and users. FSP’s support identity and attributes provisioning, as detailed later in this section. The approach we propose supports two types of negotiation. The first type is between a FSP and the user, and the second is between two FSP’s in the same federation. Regarding the first type of a negotiation a further distinction is needed. Indeed, the negotiation protocol for negotiations carried out between FSP’s and users depends, in turn, on the type of the interacting user. Precisely, the distinction is based on the membership of the user with the federation. A user is a member user of the federation if she is affiliated with an organization within the federation. The federation is more likely to have information about a member user even if she has not accessed any of its services. This also depends on the policy of the member organization that defines which of its affiliated user attributes are federated. The member will be identified among the federation with a SSO user identification. On the contrary, external users have to provide all required attributes at their first negotiations. The first negotiation between an external user and a FSP includes identity provisioning, since the provider issues a temporary user-id to be used within the federation. The use of time-limited SSO id for non-members ensures identity linkability, though limited in time, for non-members.5 Of course, users might have multiple identities and choose which one to adopt for requesting access to service. We do not elaborate on multiple identities issues since it goes beyond the scope of this discussion. By interacting further with the federation, the amount 5
We can reasonably assume that the time interval duration is defined by the federation policy.
7
Figure 2: Architecture for FAMTN Service Provider. of information about users which is disclosed to the federation increases. This information can be linked to the user (who is then called repeated external user) and thus reused in the subsequent negotiations. As a result, more efficient negotiations with fewer attributes required from the user are executed. An example is given in Figure 1. User U requests service from service provider SP1. SP1 requires user attributes (a,b) to satisfy its service policy. U provides (a,b) and gets the service. Suppose that U , at the end of this successful negotiation, opts for sharing attribute (a) within the federation, and suppose that then U requires a service from another provider SP2 in the same federation. Suppose that the attribute requirements there are (a,c). In this case, however, U only has to provide the attribute c to receive the service. At the end of a successful negotiation users receive one between two types of ticket. The first, referred to as trust ticket, is issued to non-member users in order to provide information about the previous services and FSP’s the user has accessed. The other type of ticket, referred to as session ticket, is issued to non-member users. We show a detailed negotiation process using the described user cases in Section 4.3. The second type of negotiation occurs between two FSP’s. Such type of negotiation is useful when a user successfully negotiates a service from one FSP, and she automatically becomes eligible to receive service from another FSP. As such, when the user asks for a service the FSP providing it can directly negotiate user-related attributes with the FSP holding such attributes from previous negotiations. Also, negotiations among FSP’s might be required for verifying external user identities. As we do not rely on a single IdP, an IdP might not be aware of the last registered users. When a request from a locally unknown user-id is received, FSP can directly interact with the SP that has issued the claimed user-id to double check its validity.6
3.1 Architecture of Service Providers in FAMTN A FAMTN framework is composed of FSP that contain the necessary components required to execute: 1) trust negotiation among users and FSP’s; and 2) federation of user attributes. The architecture of FSP is sketched in Figure 2. FSP is equipped with components deriving from the two underlying frameworks of automated trust negotiations and federated identity management. Each FSP can perform the functionality of an IdP and SP. The main components of the FSP are described as follows. The first is the web services component required to enable secure communication within the federation and with the users. The second is the user negotiation component which contains the modules executing the negotiation, depending on the type of user, that is, member and non-member. This component is directly related to the management layer for trust tickets. The policy base in the policy management component stores the authentication and access control policies. The credential 6
For simplicity we assume user-id contains FSP information to easily identify the issuer.
8
Figure 3: Liberty ID-WSF and FSP Example: Three websites and system modules management system is in charge of managing and validating certificates and user tickets by verifying the FSP’s signatures. It is also responsible for revocation when required. The attribute negotiation system consists of the main components required for negotiation, including: the Tree Manager, storing the state of the negotiation; the Sequence prediction module, for caching and managing previously used trust sequences, user profile information; and finally the Compliance Checker, to test policy satisfaction and determine request replies during a negotiation.
3.2 An Example of a Use Case: FSP in Liberty Web Services Framework Figure 3 gives an example scenario of the Liberty Web Services Framework (WSF) [7] with additional FSP components. For details on the original Liberty-ID WSF example we refer the reader to Section 6.1 of [7]. We now discuss how ATN comes into play in a typical identity framework. 1. User Joe makes access to SP1 using SSO. 2. Using redirection and IdM system protocols, IDP transmit SP1 a SAML assertion authenticating Joe. 3. SP1 requires a certificate from Joe to verify that he is older than 21 and his address for delivery. 4. Joe does not trust SP1 and therefore he is not willing to reveal SP1 his certified credential. He therefore negotiates with IDP and reveals his credential to IDP instead. 5. SP1 now negotiates with IDP which finally sends a SAML assertion stating whether Joe satisfies SP1’s age criteria or not. Joe does not thus have to reveal the actual credential to SP1, thus making sure that the credential is only stored with a party he trusts. 6. Joe also registers his address with SP1 for delivery but imposes as condition that his address should only be released to a member of the federation only when the address is required for a purchased product delivery and the member is certified by Better Business Bureau (BBB). 7. Joe subsequently makes access to SP2 where he orders a pizza. Due to SSO he gets seamless access. 8. SP2 asks Joe for his address. Joe 7 tells SP2 to get his profile from other sites in the federation. Using the discovery service SP2 contact SP1 who first negotiates with SP2 to verify the conditions for Joe’s attribute release is met. If successful, SP2 receives the required information and can make the appropriate delivery. This example demonstrates how additional privacy and flexible policies can be implemented with ATN. Also not all components of FSP are required in a typical IdM system. FSP can leverage from modules that are part of the Liberty Alliance Framework or other IdM systems, like the DS, PP, policy and credential management 7 Note that in this case, it is actually an agent operating at the client on behalf of Joe that actually suggests request re-directions. We use Joe to simplify the presentation of the example.
9
systems. In Figure 3 the ATN specific parts (the non-striped components) are the subset of the components of an original FSP which are used for ATN in the Liberty WSF framework.
4 Negotiations in a FAMTN Federation In this section we elaborate on the approach we have devised for negotiating trust in FAMTN. We first introduce the notion of trust tickets and session tickets, as they are the main building blocks in our trust negotiation protocols. We then propose a possible implementation of trust tickets through cookies. Finally, we illustrate our algorithm for approaching negotiations in FAMTN.
4.1 Ticketing system in a FAMTN Federation The two types of tickets supported by our framework are temporal with a fixed lifetime. We assume loosely synchronized clocks in the federation. We use the SSO id as the user-id in the tickets. Structure and functions of the tickets are discussed in what follows. Session Ticket A session ticket ensures that if the negotiation ends successfully and the same user requests the same SP for the same service in a subsequent session, the service can be granted immediately without unnecessarily having to repeat the trust establishment process. A session ticket therefore contains the following fields: SignedSP < τ (sreq ),u, T, R> where τ (sreq ) denotes the service requested, u is the user-id and T is the ticket time stamp. Here, R denotes the result of the negotiation. R might be either a simple statement or a structured object. The use of structured objects is particularly interesting for tracing intermediate results of negotiations of aggregated services. A session ticket is signed by the SP, which actually authenticates it giving a receipt of the trust establishment. Since session tickets are encrypted with the SP’s private key, they are tamper proof and can be verified. The time-out mechanism depends on the type of user attributes required for the service, and the security level of the service. Trust Ticket The purpose of the trust ticket is to determine the list of previous services external users have accessed. Assuming that all the service providers are members of the same federation, the signature of a member provider can be verified by any other member provider. Such a ticket has the following form: SignedSPlast < list{τ (s), F SP, T },u,T -I > Every 3-tuple in the list contains the type of service, the corresponding SP and the timeout. u corresponds to the temporary user identification, and T -I is the expiration date for this id. The ticket is signed by the last service provider with which the user had a successful transaction. At the end of a successful transaction, the SP takes the current user trust ticket, removes all timed out entries, appends its information, signs it and sends it to the user.
4.2 Implementing Trust Tickets through Cookies Cookies may be used with many IdM systems to make available servers information about the users. State information is stored at the client and is then sent to the server the next time the user accesses that server. Like the tickets described in the previous section, cookies can be valid only for the session during which have been issued or can persist beyond the end of the session. A persistent cookie is typically written to a file on the browser’s hard drive, if its lifetime has not elapsed when the browser is shut down and therefore can be used for a longer period of time. In a truly distributed federation if there is more than one IdP’s, a SP needs a mechanism 10
to determine which IdP has the user information. This problem is known as the “Introduction Problem” in the Liberty approach. The current approach is to rely on cookies for redirecting IdP’s. There are several advantages of using cookies. Implementing them is efficient, as there is no requirement of new software installation for their use, and they can be used independently from any authentication mechanism. They also provide dynamic state information which is helpful to prevent several security threats. One such threat is impersonation attack, which arises because when a user has successfully logged into one SP, the different SP’s in the federation do not re-authenticate her. Thus if the authentication is no longer valid, because of attacks or other failure, there is no straightforward way to detect it. Cookies help in checking whether the authentication ticket is associated with the user identity as well as the validity of the IdP session of that user. Alternatives to the use of cookies for the “Introduction Problem” are based on interactions with the user either actively or on the use of statically hand-configured list of possible IdP’s of the user. Such approaches inhibit the seamless SSO process and are not as efficient. Cookies however have some security problems [14]. Firstly, they are usually in clear text. Their headers are generally unprotected and even the encrypted cookies are vulnerable to replay attacks. Second, since the cookies are stored at the local machines they can be easily read by anyone using this machine. Thirdly, there is a need to control where a cookies are sent, because it is not desirable to send the user cookie to an untrusted service provider. For example, currently several spyware applications exploit user cookies and therefore we need a better control on the destination of cookies. As a consequence, cookies should not store any personal identifiers or any sensitive information. In real applications, however, a cookie typically stores the SSO user ID, or other tracking record which may leak information about the user. Most of these security vulnerabilities can be addressed by better storage and usage protocols and mechanisms. We propose implementing trust tickets using cookies in IdM system, to exploit the cookies advantages and prevents several of the above vulnerabilities. Indeed, the timeouts and signed information given by the session and trust tickets give reliable and dynamic state information. To further increase the security of cookie usage in a federation, mechanisms enabling selective download of cookies should be employed. Browsers typically give users limited choice about how to handle cookies. There is only coarse grained control on cookies: either no cookies are to be downloaded or all cookies have to be accepted. The case where a user can choose cookies from web site that uses a single domain vs. multiple domains may cause problem in federation which is typically a multiple domain environment. Building server filters is currently complicated and not usable by average users. Like privacy preferences, a user should be able to set preferences for the cookies, specifying more fine grained conditions. The following are examples of selective use of cookies: 1. Accept only signed cookies from a given federation SP. 2. Accept cookies from members certified by BBB by negotiating servers’ attributes. 3. Send the cookie which does not contain personally identifying information. 4. Send cookie to a SP which is not in a conflict of interest class for the SP which set this cookie. We need a policy language to express these preferences which can be integrated with the storage and usage mechanisms of cookies.
4.3
Negotiation in Identity Federated Systems
The negotiation process for trust establishment depends on the type of the involved user and the history of her interactions with the federation members. Algorithm 1 shows the complete negotiation process developed for FAMTN which includes all user cases, assuming one federation is in place. Multiple federations with nonempty intersection are outside the scope of this paper. The two main types of negotiations are between the user and the FSP’s, and between the FSP’s. The four different user cases give the basis of the design and analysis of the user- FSP negotiation process. Intuitively, a recent user should obtain service access faster than a new user. This is achieved with the help of the short termed session tickets. Similarly, a repeated user, who already received services from different FSP’s of the federation, should get service access faster than a new external user. This is because the new external user directly negotiates all the required attributes with the FSP, whereas 11
for a repeated user some of the attributes can be retrieved from the other FSP’s she has visited before. The information about the previously visited FSP’s is given in the list of trust tickets which are retrieved iteratively until user attribute requirements are satisfied. At each iteration the FSP requiring the user attributes to satisfy its service disclosure policy negotiates with the FSP indicated in the trust ticket. If the retrieved attributes do not suffice, the FSP negotiates with the user herself. Finally, a member user, being internal to the federation thus being more trusted, should have advantages in the negotiation process as compared to a new external (nonmember) user. Indeed, member user attributes are directly retrieved from the organizations in the federation within which users are affiliated. This provides an efficient mechanism for retrieval of users attributes, as it avoids iterated negotiations among all the SP’s a user has interacted with. Here we assume that all of the member users attributes are stored and possibly certified by the affiliated organization. Member users can also use the session tickets just like the external users.
5 Conclusion and Future Work As digital identity management systems and trust negotiation systems are two technologies with many common goals, it is important to clearly assess their differences and their similarities in order to better understand the potential advantages deriving from their integration. In this paper we develop such a comparison, by identifying a number of relevant criteria, and survey the most relevant initiatives and projects. Based on such an analysis we integrate federated identity management with trust negotiation techniques, such as those provided as part of the Trust-χ [3] system. We have identified several issues which need to be addressed, including questions regarding policies, that is, policy compliance and subsumption of policies. The language to define the policies should use vocabulary well understood not only by users and organization, but among the whole set of organizations. This may not be a realistic assumption and we would need to look into alternatives. Policy languages supporting the specification of credential sharing within a federation do not exist and will be useful for better privacy control in a federation. Another important problem is the representation of attributes. This is essential for efficient lookup if several users are using the system. Also the meaning of the attribute and its underlying logic can help to infer implications between conditional attributes.
6 Appendix Table 2 provides a survey of some existing examples of federations.
References [1] D. L. Baumer, J. B. Earp, and P. S. Evers. Tit for Tat in cyberspace: Consumer and Website Responses to Anarchy in the Market for Personal Information. North Carolina Journal of Law and Technology, 4(2), 2003. [2] E. Bertino, E. Ferrari, and A. Squicciarini. Privacy preserving trust negotiations. 4th International Workshop on Privacy Enhancing Technologies, May 2004. Toronto, Canada. [3] E. Bertino, E. Ferrari, and A. C. Squicciarini. Trust-χ: A Peer-to-Peer Framework for Trust Establishment. In IEEE Transactions on Knowledge and Data Engineering, pages 827– 842. IEEE, July 2004. [4] P. Bonatti and S. Kraus. Foundations on Secure Deductive Databases. IEEE TKDE, Transactions on Knowledge and Data Engineering, 7(3), pages 406–422, 1995. [5] P. Bonatti and P. Samarati. Regulating Access Services and Information Release on the Web. 7th ACM Conference on Computer and Communications Security, November 2000. Athens, Greece. 12
Working Group SWITCHaai Federation [11]
InCommon [10]
HAKA Federation Finland [9]
Microsoft, IBM, and the WS- Roadmap
Liberty Alliance
Description The SWITCHaai Federation is a group of organizations like universities, hospitals and libraries, that have agreed to cooperate regarding inter-organizational authentication and authorization. They operate a Shibboleth-based authentication and authorization infrastructure (AAI). By using Shibboleth authentication and authorization technology, InCommon intends to make sharing of protected resources easier, enabling collaboration between InCommon participants which protects privacy. Access decisions to protected resources are based on user attributes contributed by the user’s home institution. InCommon became operational on 5 April 2005. The HAKA Federation in Finland entered its production phase in late 2004. The Federation was set up in 2003, currently including 2 (of 20) universities and 1 (of 29) polytechnics as Identity Providers, and 4 service providers, including the National Library Portal (Nelli). In Finland, the libraries in higher education traditionally co-operate widely in licensing electronic journals. It is based on Shibboleth. In April 2002, Microsoft and IBM published a joint whitepaper outlining a roadmap for developing a set of Web service security specifications. Their first jointly-developed specification, WS-Security, offers a mechanism for attaching security tokens to messages, including tokens related to identity. The Liberty Alliance is a consortium of approximately 170 companies that develops specifications for federated identity management. It works on creating a single comprehensive federated identity specification. In March 2003, it released a new blueprint that described three separate specifications that can be used together or independently: First is the Identity Federation Framework (ID-FF) allows single sign-on and account linking between partners with established trust relationships. Second is Identity Web Services Framework (ID-WSF), allows groups of trusted partners to link to other groups, and gives users control over how their information is shared. Finally Identity Services Interface Specifications (ID-SIS) will build a set of interoperable services on top of the ID-WSF.
Table 2: Federation Examples
13
[6] A. Hess, J. Holt, J. Jacobson, and K. E. Seamons. Content-triggered trust negotiation. ACM Trans. Inf. Syst. Secur., 7(3):428–456, 2004. [7] https://www.projectliberty.org/specs/liberty-idwsf-overview v1.1.pdf. guidelines.
Liberty id-wsf implementation
[8] https://www.projectliberty.org/specs/liberty-trust-models-guidelines v1.0.pdf. Liberty trust model guidelines. [9] http://www.csc.fi/suomi/funet/middleware/. Haka federation finland federation. [10] http://www.incommonfederation.org/. Incommon federation. [11] http://www.switch.ch/aai/documents.html. Switchaai federation. [12] Identity-Management. Liberty alliance project. http://www.projectliberty.org. [13] Internet2. Shibboleth. http://shibboleth.internet2.edu. [14] V. Samar. Single sign-on using cookies for web applications. In WETICE ’99: Proceedings of the 8th Workshop on Enabling Technologies on Infrastructure for Collaborative Enterprises, pages 158–163, Washington, DC, USA, 1999. IEEE Computer Society. [15] K. E. Seamons, M. Winslett, and T. Yu. Limiting the disclosure of Access Control Policies during Automated Trust Negotiation. Network and Distributed System Security Simposium, February 2001. San Diego, CA. [16] K. E. Seamons, M. Winslett, and T. Yu. Protecting privacy during on line trust negotiation. 2nd Workshop on Privacy Enhancing Technologies, 2002. San Francisco, CA. [17] H. Skogsrud, B. Benatallah, F. Casati, and M. Q. Dinh. Trust-serv: A lightweight trust negotiation service. [18] M. Winsborough and N. Li. Safety in Automated Trust Negotiation. In IEEE Symposium on Security and Privacy, Oakland, CA, May 2004. [19] W. H. Winsborough and N. Li. Protecting sensitive attributes in automated trust negotiation. ACM Workshop on Privacy in the Electronic Society, November 2002. [20] T. Yu and M. Winslett. A Unified Scheme for Resource Protection in Automated Trust Negotiation. In IEEE Symposium on Security and Privacy, Oakland, CA, May 2003. [21] T. Yu, M. Winslett, and K. E. Seamons. Supporting structured credentials and sensitive policies through interoperable strategies for automated trust negotiation. ACM Transactions on Information and System Security, (6)1, feb 2003.
14
Algorithm 1 FAMTN-negotiation process Require: userID, userAuthenticationInf o Ensure: IsRegistered(userID) 1: userRequest ⇐ getRequest(userID) 2: if userRequest ∈ / ServicesF SP then 3: return Abort-Negotiation 4: end if 5: *Comment: For Members* 6: if isV alidM ember(userID) = true then 7: sessionT icket ⇐ getSessionT icket(userID) 8: if sessionT icket 6= N U LL ∧ sessionT icket.time < timeout then 9: return OK 10: end if 11: MF SP = getM emberF SP (userID) 12: remAttrList1 ⇐ N EGOT IAT EF SP (CurrF SP , MF SP 13: userID, userRequest) 14: if remAttrList1 6= N U LL then 15: remAttrList2 ⇐ N EGOT IAT EU ser (CurrF SP , 16: userID, CurrP olicyF SP ) 17: else 18: send(SessionT icket) ⇒ userID 19: return OK 20: end if 21: if remAttrList2 6= N U LL then 22: return Abort-Negotiation 23: else 24: send(SessionT icket) ⇒ userID 25: return OK 26: end if 27: end if 28: *Comment: For Non-Members* 29: F SP list ⇐ getT rustT icket(userID) 30: while F SP list 6= EmptyList do 31: Mi = rmHeadOf List(F SP list) 32: remAttrList3 ⇐ N EGOT IAT EF SP (CurrF SP , Mi 33: userID, userRequest) 34: if remAttrList3 = N U LL then 35: send(T rustT icket) ⇒ userID 36: return OK 37: end if 38: end while 39: if remAttrList3 6= N U LL then 40: remAttrList4 ⇐ N EGOT IAT EU ser (CurrF SP , 41: userID, CurrP olicyF SP ) 42: end if 43: if remAttrList4 6= N U LL then 44: return Abort-Negotiation 45: else 46: send(T rustT icket) ⇒ userID 47: return OK 48: end if 15
