Harmonizing Service and Network Provisioning for ... - IEEE Xplore

Harmonizing Service and Network Provisioning for Federative Access in a Mobile Environment David J. Lutz, Patrick Mandic, Sascha Neinert, Ruth del Campo, Juergen Jaehnert Rechenzentrum Universitaet Stuttgart Stuttgart, Germany Email: {lutz, mandic, neinert, delcampo, jaehnert}@rus.uni-stuttgart.de Abstract—In this paper we propose an integrated platform to power the symbiosis between networks and services whilst supporting mobility of users. This platform is based on methods for authentication, authorization and payment of services in a roaming environment. Existing technologies are combined and enhanced to provide a blueprint for a platform to leverage the interaction of services with the underlying network. Traditionally, such functions as discovery, authentication and authorization exist in parallel for networks and for services, without any association between the systems. This rigid layered approach is abandoned in favour of one that is more integrated and allows these functions to be reused rather than duplicated. Payment is treated as an essential and inherent part of the architecture, in order to facilitate its commercialization and adoption.

I. I NTRODUCTION For network operators, the simple transport of information is no longer appealing as it was in the past, as large investments in physical infrastructure are subjugated by seperate service providers who make extensive use of these infrastructures spawning copious benefits for themselves [1]. Within the IT sector, Web Services and Service Oriented Architectures (SOA) might be the enabling technologies that overcome the IMS drawbacks. Within the AKOGRIMO project [2], the concept of a Virtual Organization (VO) basically providing a BPEL [3] controlled environment for such complex service composition has been extended towards Mobile Dynamic Virtual Organizations (MDVOs), which consider additionally the requirements for mobile users and mobile resources. The bootstrapping in this architecture begins with network discovery, followed by an authentication and authorization process; network access is granted and payment to the network operator is launched. Afterwards, a service discovery process is started followed by service authentication and authorization triggering a service payment process. In order to achieve user acceptance, this bootstrapping process is, on one side, time critical, since users would like to access their services directly without additional delays caused by, e.g., the fact that an access operator does not maintain service federation with the desired service provider. An integrated architecture is required, which optimizes this process and instigates the symbiosis between services and underlying networks. This paper intends to present a smooth and consistent solution where each process takes advantage of previous processes, in such a manner that it requires less individual

978-1-4244-2066-7/08/$25.00 ©2008 IEEE

efforts due to a major group effort. This paper shows complete sequences for user-centric interactions with the network by using typical network technologies combined with service technologies, thereby creating one homogeneous platform. Discovery technologies, authentication processes as well as Single Sign On (SSO) procedures, authorization mechanisms that use previous infrastructures and, at the top, payment mechanisms are modified to be used optimally by networkand web-services. The rest of the paper is organized as follows: After the introduction, an overview of related work is given. Next, the building technologies of the platform as presented are described, the architecture of the platform is shown and its implementation is detailed. Finally, we draw our conclusions. II. R ELATED W ORK The idea of a federated authentication and authorization infrastructure is not new, since there already exists a number of different approaches. However, they were all developed to fulfill special needs for specific communities, so none of them can be seen as a general solution for an overall service access mechanism in a mobile world. The Grid community started very early to set up federation management structures like CAS [4], Akenti [5], PERMIS [6] and VOMS [7], and the web community followed with approaches such as Shibboleth, Liberty Alliance and WS-Fed. A. Shibboleth and Liberty Alliance Shibboleth [8] offers a SAML based [9] Single Sign On (SSO) solution for large federations. It allows the users to request a resource without having being authenticated there beforehand. Also, the user does not need to have federation specific credentials. Authentication is carried out once and after that only authorization issues have to be considered because, following authentication, a browser profile or artifact based on SAML is generated for the user that can later be used to authenticate him at his Identity Provider. Due to the fact that each authorization is done separately with new requested attribute assertions, the user can decide (by defining a policy at his Identity Provider) which information should be sent to the resource provider. Shibboleth is constrained to federations that use browsers and HTTP to provide access to the resources. This may cause problems in broad federations, since they may possibly use other protocols. The federation, proposed in our

843

framework, is SAML based and follows many ideas that were developed for Shibboleth and Liberty Alliance. The Liberty Alliance [10] is similar to the Shibboleth approach. It was also developed for the web, to be used with browsers and HTTP. The main differences between Liberty Alliance and Shibboleth are at another level than the basic model architecture. It is expected that in future the differences between Liberty Alliance and Shibboleth will be mainly in the Identity Management Space. Liberty Alliance offers, unlike most of the approaches, the possibility of a Single Log Out and provides a concept for using it in wireless federations. Like Shibboleth, Liberty Alliance is built upon the SAML Single Sign On Browser/Artifact profile, which has been criticized as being imprecise and vulnerable [11]. B. Web Services Federation Web Services Federation (WS-Fed) [12] is part of an overall effort by IBM and Microsoft to build a web services security framework, or WS-Security. This approach can be used for web service requestors using SOAP [13] as well as web browser (access with HTTP) requestors. The main components in the WS-Federation are a requestor that requires access to a restricted resource, the resource, which may have specific restrictions related to its access, and an Identity Provider combined with a Security Token Service (STS). The requestor uses either his web browser or a requestor service to ask the resource for access. The Identity Provider performs authentication and can make identity claims within issued security tokens. Attributes are received from the Attribute Server (can be combined with the Identity Provider). If pseudonymity is required at the resource, the Attribute Service is enhanced by a Pseudonym Service, which aligns the requestor’s attributes to a pseudonym. The authorization is done by an Authorization Service, a specific instance of an STS that operates in a decision brokering process. III. A RCHITECTURE The Integrated Services provisioning platform relies on three different architectural units: network, services and federation. The network unit provides ubiquitous access to mobile users. Services have to follow an architectural approach for discovering them in the network, since roaming and mobility introduce a dimension of constant change of the service topology. It is assumed that services and consumers are acting within a federated structure to establish a higher level of trust, security and convenience. Thus, the third architecture unit is that of the federations, offering federative convenience like established trust and high security to the participants. A. Network Unit The network unit for this approach must provide users’ mobility and a reliable, secure and scalable basis for the other components presented in the following sections. Roaming users have a Mobile Terminal (MT) with a supplicant (SU) installed that communicates with the next available Point of Access (PoA) using an encrypted channel.

The PoA is part of a wired local IP network and has an existing connection to an Access Router (AR). The AR has two functions: Firstly, it provides information about the available networks. Secondly, it enforces controlled access to those networks. Access requests are forwarded from the AR to an Authentication Authority (AA) server. The AA is responsible for authenticating all users of its domain. After successful authentication, the AR requests attributes from the AA for the specific user and forwards these attributes to the local Policy Decision Point (PDP) in an authorization request. The access acceptance is then parameterized according to the authorization decision and sent back to the SU. Simultaneously, a token is sent from the AA to the SU that represents the signed-on state, thereby enabling Single Sign On for further services. Whereas PoA, AR and PDP always belong to the local security domain, in the roaming scenario the AA belongs to a foreign one, called the home domain of the respective user. B. Identity Federation Unit Multi-Domain Federations occur in large networks, where services and access points are distributed over more than one domain. We propose that the owners of different components in such a federation have contracts and trust each other, but that the systems for A4C1 are distributed over several domains. In general, a federation can be seen as an association of three kinds of participants: Customers (C) or users, who wish to access services and consume resources, Service Providers (SP) who offer services to the Customers and Identity Providers (IdP), which store the information a customer has to submit for authentication/authorization in a Single Sign On (SSO) environment. In this paper, it is shown that this traditional federation concept should be extended to fulfill the requirements of an Integrated Services Access Platform. Services provided in one domain should be offered to users from outside this domain to increase earnings. Using such a federation with SSO means dealing with problems in the authentication/authorization phase: Different parts of a user’s profile have to be transmitted from his IdP to several SPs. It is assumed, that the customer has a contract with at least one IdP-owner that hosts his profile data, e.g. his home network provider. In that context, the term user’s Home IdP is used and the domain that contains this IdP is named the user’s Home Domain. C. Service Discovery Unit As mobility becomes an integral part of the new network architecture, not only components such as location and context changes becomes relevant, but also another dimension such as roaming through different network administration areas is added. A component needs to be added to permit access to services in the visited as well as the home domain. Service discovery mechanisms are composed by a Service Provider (SP), which offers a certain service, a service requestor and sometimes a directory. A directory becomes necessary for scalability reasons, but it also eases the deployment of 1 Authentication,

Authorization, Accounting, Auditing, Charging.

844

a certain structure inside the network and therefore is typically used in infrastructure networks. Next Generation Networks (NGN) usually strive to provide infrastructure-based solutions and hence this is the approach followed in this work. One or more Service Directories are expected to exist in each administration area. In the context of the AKOGRIMO project, a SIP [14] based Service Discovery was developed, to overcome drawbacks of current infrastructure mechanisms by providing: Firstly, a subscribe-notify framework, which augments the typical current query result or broadcast mechanisms and secondly, relative independence from the type and format of service description used. XML and XPath queries can be used as well as slp-type querying with plain text; and roaming support. IV. I MPLEMENTATION This section explains how network discovery, identity provisioning, service discovery and payment provisioning in service-provisioning infrastructures are achieved in an integrated fashion. Inherently, multi-domain federations with their trust-relationships and their distributed A4Cs cover the gap that technologies like SIP, SAML and Diameter [15] cannot cover. A. Network Discovery and Access When a user desires to use some kind of service, the first step is to discover the most suitable network to use out of those available. The information provided about the network by current technologies is however rather scarce ( 802.11 networks broadcast the name of the network). However, regular wired networks do not even offer that. Due to the great variety of network types that can be used in mobile devices, these mechanisms should be independent of the type of access network used. To solve this, we propose different solutions at L3 or above. Useful information can be the price of use, name of the network, direction of the authentication authority (AA), the direction of a local SIP proxy or a textual description. This information can be conveyed in different ways in IPv6 such as embedding the information in router advertisements or by using DHCP. The approach that was followed in our work was the use of DNSSD which seems to be most lightweighted and flexible method. For scenarios with a great amount of networks, other more efficient methods should be studied, like the use of 802.21[16], which also provides network technology independence. Once this procedure is over, the user’s SU sends an access request to the AR of the chosen network. The AR acts as a Diameter client and forwards the request to the AA in the user’s home domain. Diameter serves here as a transport protocol for SAML. Except for this difference, further authentication and authorization steps are processed in the same way as for any other service, as described in the following section. B. Identity Provisioning The Identity Provisioning is done using the federation architecture. It is desired that a user has to login only once; afterwards he should be able to access all federative institutions

without a further login (SSO). This convenience requirement can be achieved using SAML. SAML over SOAP or Diameter can be used to transmit messages between user, IdP and SP. SAML is in general used to generate assertions, stating user information related to authentication and authorization: The first time a user needs to authenticate, he accesses his IdP, where he logs in and submits his credentials. After successful login, the IdP generates a SAML Authentication Assertion, which is used every time the user needs to re-authenticate, e.g. to a different federation member, and sends a reference to that assertion to the user’s mobile device. Each time the user needs to authenticate, he presents that reference (IDToken2 ) to the requesting entity. The requestor, in turn, is able to get the full assertion from the user’s IdP which it trusts, due to the federation contracts. Alternatively, the IdP can issue the whole assertion to the user. Since it has use-conditions, lifetime and an IdP-signature, so the entity, where the user authenticates, can trust the assertion. For authorization purposes, the user must first be authenticated. After receiving his IDToken or authentication assertion, the SP can request the user’s profile attributes from his IdP. These attributes, submitted within a SAML Attribute Assertion, are given to the PDP of the SP. Based upon its decision, the user request for access is granted or denied or perhaps allowed with different constraints and QoS depending on the specified attributes. This approach for a two-step access-decision - firstly a login into the federation and secondly an attribute based authorization using SAML Authentication and Attribute Assertions - provides a high level of security and privacy, since the user data is transmitted via secured protocols, without losing convenience. The user must have only one account for accessing all federated services. C. SIP-based Service Discovery This mechanism takes advantage of the subscription/notification capabilities of the SIP protocol to obtain a SIP-based service discovery mechanism [17]. This mechanism hardly imposes restrictions on the type of service description or query methods being used, and therefore existing technologies can be used on top of it (even simultaneously). Service Publication Agent (SPA), Service Discovery Agent (SDA) and Service Discovery Subscriber (SDS) correspond to service provider, directory and service consumer respectively. In a multi-domain scenario, supporting roaming and federations, the architecture needs to be augmented. This is done, once again, by making use of existing SIP mechanisms. Requests are routed by SIP proxies to the correct SDA, which depends on the domain requested being part of the federation. On arrival at the SDA, the requests are processed after crosschecking against policies that apply. On arrival at a new network, the user first needs to send a REGISTER message to the local SIP proxy, which in turn is 2 We propose a token that contains a SAML artifact as a pointer to the SAML Authentication Assertion, a Serial Number to avoid replay attacks, a Random Number for security purposes, user’s ID and the user’s signature.

845

routed to his home domain in order to update its new position in the localization database. This registration may contain an embedded token in the SIP header that the SIP proxy will use to authorize the user and fetch information such as policies, and the user’s profile. D. Payment Provisioning Payment in a federated service provisioning infrastructure is very challenging, since the conventional approaches leave out the idea of federations, e.g. by forcing the users to have submitted his credit card details. Our proposed approach leads towards a federative payment on-the-fly instead of the mainly current pre- or post-paid systems. Starting from the federative idea described in the IdentityProvisioning section, an approach for payment using the same infrastructure was developed. A Payment Provider (PP) hosts the user’s account resembling the IdP hosting his profile. Thus, by introducing this new fourth component in the federation structure, it is possible to integrate the payment in the federation with its SSO mechanism - the consumer is no longer forced to have other monetary accounts to pay for the services. Based on [18], the payment works in the same way as identity provisioning i.e. by submitting SAML assertions and tokens. The central payment statement is the Payment Assertion (PA), whose Attribute-Value-Section would look like:

For a pull-model a scenario can now be depicted as follows: The consumer requests a resource and is authorized by the above described mechanisms. Then, a payment offer is sent from the SP to him and, based on this offer, the consumer requests a PA at his PP. The PP generates the PA and sends a SAML token, i.e. a URI reference to the PA, to the consumer. The consumer presents the token to the SP and the SP, in turn, can request the PA at the consumer’s PP by presenting the token. To avoid the disadvantages described in [19], it is proposed that the URI Reference is more than just a reference by having security information as in the IDToken. We propose a Payment Token, which is built like the IDToken, containing a SAML Artifact (acting as reference), the issuer’s ID, the consumer’s ID, the currency, the exact amount, lifetime information, conditions about its usage, a transaction reference, and the issuer’s signature. Using this information, the monetary value of the token can be split up when it is received, providing the application handling it is secure [19].

V. C ONCLUSION In this paper we have presented an overall architecture, where gaps in-between network, application and federation layers have been narrowed in favour of a consistent integrated services provisioning platform, which benefits both network operators and service providers. This has been possible by the enhancement of technologies such as SIP, SAML and Diameter in their capabilities. Typical network actions such as discovery and authentication as well as SSO procedures, authorization mechanisms and payment provisioning have benefited from this new integration. While Identity Provisioning and Service Discovery are already successfully implemented in AKOGRIMO [2], other remaining infrastructures are intended to follow. An architecture for authorization in a roaming federation as well as for unified SSO is defined in DAMe [20]. ACKNOWLEDGMENT The approach published in this paper was partly developed in the projects AKOGRIMO [2] and DAMe [20], both funded by the EC under the FP6-IST programme. The authors would like to thank all the partners involved in those projects. R EFERENCES [1] Washington Post: No Neutral Ground in This Internet Battle, By Jeffrey H. Birnbaum, Monday, June 26, 2006; Page D01. [2] “Access to knowledge through the Grid in a Mobile World” (AKOGRIMO). Funded by the EC under the FP6-IST programme. http://www.mobilegrids.org/ [3] OASIS Web Services Business Process Execution Language (WSBPEL) TC http://www.oasisopen.org/committees/tc home.php?wg abbrev=wsbpel [4] Community Authorization Service (CAS) Documentation. http://www.globus.org/toolkit/docs/3.2/cas/, June 2007. [5] Akenti – Distributed Access Control. http://dsd.lbl.gov/Akenti/, June 2007 [6] PrivilEge and Role Management Infrastructure Standards Validation. http://www.permis.org/index.html, June 2007. [7] R. Alfieri et al. From gridmap-file to VOMS: managing Authorization in a Grid environment. In: Future Generation Computer Systems, 2005. [8] Shibboleth Website – http://shibboleth.internet2.edu/, June 2007. [9] N. Ragouzis et al.: Security Assertion Markup Language (SAML) V2.0 Technical Overview. October 2006. [10] Liberty Alliance Project. Liberty ID-FF Architecture Overview. 2005. [11] T. Gross: Security Analysis of the SAML Single Sign-on Browser/Artifact Profile In: Proc of the Annual Computer Security Application Conference, 2003. [12] H. Lockhart et al.: Web Services Federation Language (WS-Federation). Version 1.1, IBM Corporation, December 2006. [13] W3C SOAP Specifications, June 2007. [14] J. Rosenberg, et al, SIP: Session Initiation Protocol, RFC 3261, 2002. [15] P. Calhoun et al.: Diameter Base Protocol, RFC 3588, 2003. [16] C. Dannewitz, et al., An IEEE 802.21-based Universal Information Service, Wireless World Research Forum, 2006. [17] P. Mandic et al.: Service Discovery as a key element for Integrated Service Infrastructure Platforms. IST-Mobile summit, Budapest, 2007. [18] C. Jennings et al: Payment for Services in Session Initiation Protocol (SIP). Internet draft, 2006. [19] D. Lutz: Federation Payment using SAML Tokens with Trusted Platform Modules. In: Proc. of the IEEE Symposium on Computers and Communications (ISCC ’07), 2007. [20] “Deploying Authorization Mechanisms for Federated Services in the eduroam Architecture” (DAMe). Funded by the EC under the FP6-IST programme - http://dame.inf.um.es/

846