Identity Federation Broker for Service Cloud

Transcription

1 2010 International Conference on Sciences Identity Federation Broker for Cloud He Yuan Huang 1, Bin Wang 1, Xiao Xi Liu 1, Jing Min Xu 1 1 IBM Research China {huanghey, wangbcrl, liuxx, xujingm}@cn.ibm.com Abstract. As the wide adoption of in-cloud services (e.g., software-as-a-service), some major identity related issues are brought up. For enterprises, it usually introduces additional cost and risk to manage identities in services. For service providers, typical pairwise identity federation solutions are not scalable to support single sign-on, service composition, etc. among services for large environment like service cloud. This paper proposes an identity federation broker that introduces a trusted third party as a trust broker to simplify the management of identity federation in a user centric manner. With this solution, the cost and risk of federated identity management for both enterprises and service providers could be significantly reduced. A detailed scenario implementation is given to demonstrate the feasibility of the solution. Moreover, the vulnerability analysis shows how the solution can resist the typical security attacks. Keywords: identity federation, service cloud. 1. Introduction Nowadays more and more enterprises turn their steps to services delivered by public clouds such as SaaS (software-as-a-service) for business and IT transformation. However, the use of in-cloud services usually introduces additional accounts for users who need to access to the services. This not only creates additional risks, but also increases the account management cost especially for those having a large number of in-cloud service users. Cross service access poses additional challenges that one service needs to be able to access to user's data managed by other services on behalf of the user. Federating identities between services seems to be a natural approach to addressing the challenges. However, the traditional (identity provider level) pairwise trust model leads to quadratic complexity of federation relationships and results in a heavy implementation and operation cost for service providers. In order to fully address above issues, this paper proposes an identity federation broker that introduces a trusted third party as a trust broker for establishing identity federation between services in-cloud or across clouds in a user centric approach. It provides identity management and identity federation services to enterprises and is able to federate with enterprise's existing identity systems if there are ones. The rest of the paper is organized as follows: in section 2, the motivations of the paper is introduced to illustrate the trust model and desired system properties of the proposed solution; section 3 gives the details of solution design; section 4 uses a concrete scenario implementation to demonstrate the feasibility of the solution; the vulnerability analysis in section 5 shows how the solution can resist the typical security attacks; section 6 lists related work and compares them with the proposed solution; section 7 summarizes the paper and introduces future work. 2. Motivation The management of trust relationship among parties (services or on-premise apps) is the foundation of a federation solution. Below discusses two typical trust models respectively. (Note that, the trust models discussed in this paper are identity provider level trust models, i.e., trust models among identity authorities.) Pairwise trust model. Most existing federation solutions, such as IBM Tivoli Federated Identity Manager [5], PingFederate [8], etc., are based on pairwise trust model. In this model, relationship and business trust between all /10 $ IEEE DOI /ICSS

2 interoperating participants is exclusively governed by signed business agreements. The strong trust established via business agreements is not technically extendable which results in the forming of closed communities [2]. With this trust model, to enable cross service access among in-cloud services, external services and on-premise apps, multi-lateral trust relationships should be established. For each trust relationship, involved parties need to get business agreement and technical agreement, which really cost a lot. Brokered trust model. Another typical trust model is brokered trust model. In this model, an intermediary is introduced. The business agreement between the service provider and the intermediary places trust in the intermediary, allowing it to act as an agent for the service provider and to establish trust paths to other parties [2]. Thus, with a trustable intermediary, transitive federation could be established dynamically and to a broader range of services. In other words, the cost for establishing multi-lateral trust relationship using pairwise trust model could be dramatically reduced using brokered trust model. Moreover, the trustable intermediary could potentially act as an arbitrator and solve the disputes about cross service access. As we know, the cloud is actually a trusted party for all the in-cloud services and enterprises. Furthermore, if external services want to get connected with the cloud, they should also trust the cloud. Thus, the cloud is a good candidate of intermediary for brokered trust model in this context. Considering both benefits and feasibility, we decide to adopt brokered trust model in our federation solution for service cloud. 3. Solution Based on the selected trust model and desired properties in previous section, we come up with the identity federation broker solution, which is composed of a broker server and a set of extensible gateway (or existing identity federation solution) deployed with services or on-premise apps. In this section, an overview of the solution is given to help readers have a quick knowledge of the solution. After that, detailed design for federated single sign-on is illustrated to help readers get in-depth understanding of the solution Solution Overview Figure 1 gives an overview of the identity federation broker solution we proposed. Fig. 1. Web Web s s /REST /REST In-Cloud In-Cloud Single Sign-On (SSO) Legend Secure Backend Call Broker Server / On-Premise Gateway External External Enterprise X Corporate Directory Gateway Plug-in Existing Federation Solution Overview of Identity Federation Broker for Cloud Basically, the solution is composed of several key parts: broker server, service/on-premise gateway, and gateway plug-in. The broker server, as the core of the solution, is in charge of managing & broking the cross service access The existing federation solution, deployed with service/on-premise app, is a pre-existing identity federation solution. In this case, service/on-premise gateway is not required. The service/on-premise gateway, deployed with service/on-premise app, is in charge of collaborating with broker server to delegate the request from/to service/on-premise app. The gateway plug-in, as extension of gateway, is in charge of adapting the gateway with characteristics of identity provider of service/on-premise app. In the following, we give an in-depth introduction of transitive federated single sign-on based on our solution. 116

3 3.2. Design for Transitive Federated Single Sign-On between s This section gives detailed description on how to enable transitive federated single sign-on between services with proposed solution. Firstly, the responsibilities for involved roles are introduced. Then, system components related with the federated single sign-on are introduced. Finally, a sequence diagram by extending Security Assertion Markup Language (SAML) version 2.0 Web SSO profile [1] is given to illustrate the detailed interaction flow during federated single sign-on. System Components. In this section, we focus on the system components related with transitive federated single sign-on. Fig. 2. Broker Token Broking Store Broker Server Info Info Store Transitive Federated Single Sign-on Related Components in Broker Server As shown in figure 2, the related components of broker server are as follows: Broker Token, which is in charge of generating SAML token to target in terms of request from gateway of source. Info, which returns gateway info and required identity attributes of a. Broking Store, which stores the transitive federation relationships for cross service access. Info Store, which stores gateway info and required identity attributes of a. Fig. 3. Credential Capturer SSO Gateway Authentication Credential Capturer Provider Assertion Consumer Transitive Federated Single Sign-on Related Components in Gateway As shown in figure 3, the related components of service gateway are as follows: SSO, which is in charge of getting SAML token to target from broker server and redirecting user to gateway of target. Credential Capturer, which is in charge of interacting with source service to capture credential of current authenticated user. Assertion Consumer, which is in charge of validating the token embedded in request and redirecting user to target. Authentication Provider, which is in charge of interacting with target to autologin user into the target. Interaction Sequence of Transitive Federated Single Sign-on. Basically, the interaction sequence can be divided into five phases: Phase One - the user logins source and triggered the SSO to target. Phase Two - the gateway of source interacts with source to get current authenticated user s credential. Phase Three - the gateway of source interacts with broker server to request SAML token for accessing target and get the endpoint of assertion consumer service on target side. The interaction steps in this phase are similar as the steps in SAML2 Web SSO Profile [1]. Phase Four - the gateway of target interacts with target to help user auto-authenticate with the target. Phase Five - the gateway of target redirects user to target. As the user has been auto-authenticated with the target, the target returns the expected resource to user. 4. Sample Scenario Below we use a detailed scenario to demonstrate how the proposed solution could work in real world Business Context CP is a trusted cloud provider, which hosts some third party business services, such as sales service provided by SF. COLL is another service provider, which offers a collection of online collaboration services, such as activity service, file & share service, outside the cloud. Both SF and COLL have established business partnership with CP. A small company, MyCompany, has subscribed both sales service and collaboration services for its salesperson. 117

4 From MyCompany s perspective, it would like to enable the federated single sign-on between these subscribed services to improve salesperson s productivity and reduce the cost of helpdesk Scenario Implementation In this scenario, the client admin of MyCompany can take full control over the federated single sign-on between sales service and collaboration services. Firstly, the admin needs to assign accounts of sales service and collaboration services to members of MyCompany. Table 1 shows the accounts assigned for Tom Li. Table 1. Tom s Account ID in Different s Name Sales Collaboration Account ID tom_li tom@mycompany.com Secondly, the admin simply create a cross service access between sales service and collaboration services as shown in Table 2: Table 2. Cross Access Configuration for Single Sign-on from Sales to Collaboration Fig. 5. Interaction Flow between Source Gateway and Source Figure 5 shows how gateway of sales service can get Tom s credential. Detailed steps are as follows: 1. Tom logins sales service as tom_li. 2. Tom clicks a link in sales app to navigate to activity app of collaboration service. 3. The WAS plug-in gets LTPA token of current authenticated user (Tom), and get his credential. 4. The WAS plug-in redirects Tom s credential to Gateway s credential capturer, which executes the following steps as depicted in sequence diagram of previous section. Source Target Cross Access Type Sales Collaboration Single Sign-On In the process aforementioned, the admin does not need to understand any security or federation related concepts. As federation is required for enabling single sign-on between these two services, the transitive federation between them is established transparently underlying. The basic interaction sequence of transitive federated single sign-on has been given before. To help readers get in-depth understanding on how to integrate gateway with services, detailed interaction flows between gateway and services are given as below. Fig. 6. Interaction Flow between Target Gateway and Target Figure 6 shows how gateway of collaboration service can help Tom access activity app without additional sign-on. The detailed steps are as follows. Note that, the previous steps are skipped here. 118

5 1. The authentication provider of gateway redirects Tom s credential in collaboration service to OpenID plug-in to autologin OpenID provider. 2. After autologin, the OpenID plug-in redirects Tom back to the gateway. 3. The gateway redirects user to activity app. The following steps just follow typical interaction flow between OpenID consumer app (activity app) and OpenID provider. As Tom has already autologined the OpenID provider, he can access activity app without additional sign-on. 5. Vulnerability Analysis Due to the nature of identity federation broker as a federation solution for service cloud, deliberating security consideration is critical to make the solution success. A detailed vulnerability analysis is conducted in this section for the transitive federated single sign-on between services based on our solution. In this analysis, typical security threats and possible countermeasures are illustrated. Note that, the interaction sequence from source gateway to target gateway is the same as typical SAML2 web SSO profile. For SAML2 Web SSO Profile, there is already an in-depth vulnerability analysis [10]. This section just focuses on the interactions between service gateway and broker server Attacks Denial-of- Attacks Threat: As handling token generation request in broker server or SSO request in service gateway is potentially a very expensive operation, broker and service gateway are susceptible to a denial of service (DOS) attack. Countermeasures: For token request to broker server, by restricting access to broker server to a set of known parties (trusted services), the risk of a DOS attack could be drastically reduced. More specifically, we could place the broker server inside a secured intranet and implement access rules at the router level. Man-in-the-Middle Attacks Threat: Man-in-the-middle attacks are particularly pernicious for the communication between service gateway and broker server. The MITM can relay requests, capture the returned SAML token, and relay back a false one. Countermeasures: A bilateral authentication system (e.g., HTTP over TLS/SSL with both server- and client-side certificates required) would allow both parties to determine that what they are seeing in a conversation actually came from the other party to the conversation. Replay Attacks Threat: Replay attacks amount to resubmission of the token request in order to get the SAML token to target service fraudulently. Countermeasures: In general, the best way to prevent replay attacks is to prevent the message capture in the first place. Some of the transport-level schemes (e.g., HTTP over TLS/SSL) used to provide in-transit confidentiality will accomplish this goal Collusions Collusion between two or more service providers Threat: two or more corrupted service providers can collude and mass-correlate the identities stored in their database. Countermeasures: As the transitive federation is established thru broker, and all the account linking work are done by users on broker and stored in broker, services could not cross-reference their databases. Collusion between broker provider and service provider Threat: broker provider and service provider can collude and mass-correlate the identities stored in their database. Countermeasures: The broker provider is actually the cloud provider. The assumption of identity federation broker solution is that broker server is the most trustable party of clients. Thus, we don t consider this kind of collusion in the solution. 119

6 6. Related Work There are a couple of well-known identity federation specifications and standards, such as Security Assertion Markup Language (SAML) [1], Liberty Identity Federation Framework (ID-FF) [3], WS-Federation [4], etc. While these protocols have defined well-organized interaction flows and assertion formats to support direct identity federation between two parties, there still lack of detailed interaction flows and assertion formats to support transitive (brokered) identity federation. One of the most popular identity federation products is IBM Tivoli Federated Identity Manager (TFIM) [5], which is based on open standards, such as SAML, WS-Federation, and etc. However, while TFIM adopts pairwise trust model, it does not provide support for brokered trust model. There are some other identity federation products, such as Oracle Identity Federation [6], Microsoft Geneva Server [7],, Microsoft.NET Access Control (ACS) of Azure [9], PingFederate [8], and etc. All these products do not support brokered trust model. 7. Future Work & Conclusion This paper proposes an identity federation solution, identity federation broker, to address the multi-lateral federations among in-cloud services, external services, and on-premise apps. The solution enables transitive federation based on brokered trust model. With transitive federation, service provider only needs to configure once to support potential federation with other services and on-premise apps. In the meanwhile, subscribers have full control over cross service access, which actually triggers configuration over transitive federation between services in a transparent way. Moreover, the solution is extensible to adapt to different kinds of identity federation protocols and identity management systems of services or on-premise apps. Potentially, the broker in the solution could act as an arbitrator to solve the disputes about cross service accesses. Currently, we have only implemented transitive federated single sign-on in the solution. In future, we will support more types of secure cross service access, such as secure web service call, etc. After that, we will conduct in-depth investigation on how to provide more desired properties, such as privacy, compliance, availability, etc. Moreover, we will apply the solution to real cases to gather feedbacks and requirements. References 1. Security Assertion Markup Language (SAML) V2.0 Technical Overview, stc-saml-tech-overview-2.0-cd-02.pdf 2. SAML Trust Model Guidelines, c-saml-trustmodels-2.0-draft-01.pdf 3. Liberty Alliance ID-FF 1.2 Specifications, 160/file/liberty-idff zip 4. Web s Federation Language (WS-Federation) Version 1.2 Specification, s-federation-1.2-spec-cs-01.doc 5. Federated Identity Management and Web s Security with IBM Tivoli Security Solutions, 6. Oracle Identity Federation White Paper, technology/products/id_mgmt/coreid_fed/pdf/identity_federati on_wp_10gr3.pdf 7. Microsoft Geneva, 8. PingFederate 6.0 White Paper, ils.cfm?customel_datapageid_1296= NET Access Control, Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0, r-2.0-os.pdf 120