Federation solutions for inter- and intradomain security in next-generation mobile service platforms

Int. J. Electron. Commun. (AEÜ) 60 (2006) 13 19 www.elsevier.de/aeue Federation solutions for inter- and intradomain security in next-generation mobile service platforms Hans-Jörg Vögel a, Benjamin Weyl a,, Stephan Eichler b a BMW Group Research and Technology, Hanauerstr. 46, D-80992 München, Germany b Institute of Communication Networks, Technische Universität München (TUM), Arcisstr. 21, D-80333 München, Germany Dedicated to Professor Jörg Eberspächer on the occasion of his 60th birthday Abstract A federation approach for security in future distributed service delivery platforms for mobile users offers some key advantages over an integrated solution relying on a common choice of a standardized authentication technology. By agreeing on an exchange protocol for security assertions rather than on the detailed security mechanisms, Service Aggregators and Access Network Operators will be able to federate their customer offerings flexibly and jointly offer services. The consumer will find formerly separate offerings combined, and Service Operators will enjoy open interfaces towards the network s service delivery platform. Through the use of Security Assertion Markup Language (SAML), standardized assertion statements can be made not only for the user s identity, but also on attributes and authorizations associated with it. This will allow a seamless personalized service experience offering single sign-on across separate operational domains. An example from automobile telematics is used to illustrate the concepts. 2005 Elsevier GmbH. All rights reserved. Keywords: Security; Assertion; Single sign-on; SAML; Open service provisioning; Telematics; Automotive 1. Introduction In future networks, services will be offered across multiple access technologies and network access will become even more a commodity than nowadays. The service provisioning platform capable of spanning heterogeneous access technologies and even operators and their respective networks will become a key component. Moreover, entities holding individual customer relationships, i.e. aggregators and service providers will want to bundle their services with network access contracts. They are striving for more integrated offerings with better functionality and greater Corresponding author. E-mail addresses: hans-joerg.voegel@bmw.de (H.-J. Vögel), benjamin.weyl@bmw.de (B. Weyl), s.eichler@tum.de (S. Eichler). business flexibility, such as integrated pricing and valueadded services. This functionality can hardly be addressed by simple roaming contracts, and only partially by current mobile network- and client-side service platform technologies, such as IN-based CAMEL and MExE [1]. As opposed to those rather monolithic approaches, future platforms will clearly discriminate and differentiate between access and transport infrastructure, provisioning infrastructure, and infrastructure related to pure service logic. Multiple administrative domains will emerge for various parts of this fragmented platform (with roles such as Access Operator, Provisioning Operator, Service Operator, Service Aggregator). Therefore, secure service delivery and distributed authorization will become key challenges to be mastered. This is even more important, since highly individual and personalized services will have to be securely delivered and authorized across the 1434-8411/$ - see front matter 2005 Elsevier GmbH. All rights reserved. doi:10.1016/j.aeue.2005.10.008

14 H.-J. Vögel et al. / Int. J. Electron. Commun. (AEÜ) 60 (2006) 13 19 operational boundaries of those domains. Hence, not only intra- but most importantly inter-domain security will have to be dealt with. In our work, a flexible security architecture based on a federation approach is proposed. The remainder of the paper is organized as follows: in Section 2, we discuss next-generation service architectures and analyze their needs for distributed authorization. Section 3 will briefly elaborate on the Security Assertion Markup Language (SAML) and other technologies, and then present a federation approach for future mobile service architectures. 2. Next-generation service architecture 2.1. Services for mobile users Future service delivery platforms have to accommodate mobile users and their need for a personal set of individual services. These services comprise commodity services, such as voice and IP connectivity, supplementary services, and a growing number of value-added services. While the first two are typical mobile operator offerings already in secondgeneration networks [1], it is this last category that is increasingly offered by third parties in cooperation with or even independent of the mobile operator. Examples for the diverse nature of these value-added services are entertainment services such as music subscription services or telematic services like navigation, assistance, and general driver information services [2]. Frequently, these services are defined and operated as location-based services [3]. Mobility concepts beyond third generation foresee them being delivered across heterogeneous access infrastructures [4,5]. This is a strong driving force behind new operator concepts, which clearly separate access from service provisioning and that again from service infrastructure. Services will in the future be delivered on open provisioning platforms, facilitating flexible and innovative business models [4]. In particular, the service aggregator will be a role with strategic positioning able to bundle services and offer them to end-users across multiple access network domains, both technological and operational. The aggregator is the end-user s prime contractual partner. Frequently, the aggregator will issue a digital identity, which depending on the chosen security solution will comprise credentials and/or certificates of some form. 2.2. Distributed authorization needs Besides the service aggregator, many additional roles will drive or be more clearly defined by provisioning platform developments, such as service operators, content providers, service provisioning platform operators, and access network operators. They will define complex business relationships with each other and towards consumers, but in our model it is the aggregator role that holds the central customer relationship and is ultimately liable for the service contract. Nevertheless, increasing separation and clearly defined interfaces between the operators technical platforms facilitate the formation of administrative and legal domains. In particular, service aggregators and/or service operators may maintain direct contractual relationships with consumers. The need for their services to be delivered across and independent of multiple access network infrastructures requires an integrated approach towards certain functionalities and information models, such as management of user identities, subscriptions, authorization, and personalization information. However, instead of a technically integrated solution, a federation approach should rather be followed. This will reduce tight coupling between network and service, and will allow for services to be more flexibly bundled into an offering. It will provide an open technology solution to accommodate shifting patterns of business relationships and customer ownerships. Users need to be able to sign-in to the system only once, even when accessing services across infrastructure operated in different administrative domains, e.g. when service-logic is not operated by the same entity as the network across which it is accessed. The end user should not need to authenticate, at least not manually, each time a service or rather a service infrastructure is accessed. The end user will, through the contract with the aggregator, be authorized to access services or variants thereof. These services will not be operated in one single location, but will rather be offered by several independent service providers each operating their own service infrastructure. To securely access services, end users need to be identified, their identity verified, and their authorizations in using the service determined and reliably enforced. Conversely, for a service provider to sell its service through multiple aggregators requires secure access to the respective portion of the customer database, establishing a user s identity, identifying rights and roles and authorizing service access. The service provider should be able to do this without having to create duplicate security infrastructures and deploy multiple solutions for each aggregator that his service is sold through. Correspondingly, the aggregator should be able to readily create business relationships with service providers and add services flexibly based on the chosen security solution. Further, it should be possible to flexibly bundle these offerings with a contract to use access network resources. This calls for a loose, yet secure coupling of the business platforms, federating the respective organizational and operational domains. An open way to securely exchange authentication and authorization information and the corresponding attributes has to be defined.

2.3. An exemplary application domain: telematics H.-J. Vögel et al. / Int. J. Electron. Commun. (AEÜ) 60 (2006) 13 19 15 Securely delivering services into vehicles and maintaining information security along the way for sure is a challenge that has to be faced as more complex telematics services are being defined [6]. In particular, the aggregator role already is and will be exercised by multiple stakeholders such as vehicle manufacturers (OEM), service operators focusing on telematics, and increasingly mobile operators. Some aggregators, in particular those offering services into vehicles of multiple OEMs, might not be free to choose identities and corresponding security mechanisms. As a service will be sold into many vehicles of different brands and models and through many aggregators, the service operator will have to interface with many different security solutions and authentication mechanisms. Clearly, the service provider/operator should not be required to implement all of them. Inside the vehicle we are running the risk of cluttering the dashboard yet even more with a host of devices for presenting authentication credentials such as SIM card, PIN entry pad, smartcard reader, etc. Moreover, a Single Sign-On (SSO) concept across all services will dramatically facilitate service deployment and reduce the amount of user interaction needed for secure service access. Fig. 1. Basic concept: inter-domain single sign-on. 3. Federation approach 3.1. Distributed authorization concept Instead of business stakeholders (cf. roles described in Section 2.2 above) having to agree on one single authentication technology or each embarking onto separate schemes, it is rather preferable to exchange information of their respective security decisions in a standardized format. Stakeholders trusting each other accept their respective statements on those decisions. They are said to have entered into a security federation, also known as circle-of-trust, exchanging security assertions [6]. The strong value proposition of federations relies on the fact that an assertion consumer does not need to know about how this information has been created. Based on his trust relationship with the producer, he can rely on an assertion to be correct. And because of the standardized format, a consumer will always be able to read the assertion [7,8]. Fig. 1 illustrates the basic concept of distributed authorization. An end user is securely identified (authenticated) at his portal (the source site) after having presented his credentials. The asserting authority behind the portal issues an assertion with the basic attributes and authorizations of this end user. When the user accesses an application/service, this assertion is then presented to a service center (the destination site) together with other session information, such as the user s identity. The service center evaluates the informa- tion contained in the assertion, and optionally verifies the assertion s validity with the source site. If the assertion is valid the user is granted access to the service. This works in the same way, regardless of whether the source and destination site are in the same administrative and operational domain or not, i.e. regardless of being operated by the same or by different entities. 3.2. End-user perspective Typically, for a user there will be only one source site, which is the aggregator s site. When a new user is introduced to the system, it is sufficient to register him with the aggregator serving as source site for the rest of the system, unless the service is to be personalized (see Section 3.4 below). Note that the user does not have to maintain a second set of credentials for the destination site, nor does he have to authenticate a second time when accessing the service, nor does the service center have to maintain its own credential store or a copy of the source site s credential store. Hence, the user will be able to flexibly request new services to be added to his portfolio or even subscribe to them in an increasingly easy self-provisioning approach. Security is effectively increased since his credentials are stored in one central place and he only requires one set, regardless of the number of service centers.

16 H.-J. Vögel et al. / Int. J. Electron. Commun. (AEÜ) 60 (2006) 13 19 3.3. Technologies enabling federations Various standards and frameworks have been specified and designed for enabling federated identity management. The solutions establish so called circles-of-trust, i.e. the efficient and secure linking and exchange of identity- and profilerelated information across heterogeneous domains. Entities taking the role of a relying party are able to access profile information required for authentication and authorization from an asserting party, usually also taking the role of a so called identity provider. The most important developments are SAML, Liberty Alliance, Shibboleth, and WS- Federation. Basically, the Security Assertion Markup Language SAML has been defined for the exchange of authentication, attribute and authorization information across domains. The main use case of SAML 1.0/1.1 [7] is the setup of a SSO environment. Recently, SAML 2.0 [8] has been officially released. It consolidates SAML and the specifications of the Liberty Alliance Project. The Liberty Alliance Project, aims at designing a comprehensive federated identity management framework. Use cases for a distributed, federated identity- and profile management solutions, supporting SSO and Single Log-out (SLO) are specified, respective specifications leveraging the SAML standard at least partially [9]. Another solution is being developed by the Shibboleth Project. They also base their framework on SAML and focus on extensions for enabling privacy by anonymizing the security context and providing a minimum set of attributes required for authorization. This attribute provisioning is being controlled and enforced with predefined privacy policies, which can be managed by the user [10]. WS-Federation, the competitor to Liberty Alliance, specifies how a federated identity environment is established [11]. The specified use cases embody trust-establishment across domains, SSO, SLO and attribute management. Besides these specifications, a web-services security framework, including several other specifications has been defined [12]. Only WS-Security has reached official specification status yet. A great challenge is the interoperability of all specifications and solutions. It remains yet to be seen, whether solutions will converge or several competing federated identity approaches will persist. Anyhow, the reliance of Liberty Alliance on SAML, plus SAML being the baseline technology in the Shibboleth Project places the technology into a key position. SAML has been created as an open framework to communicate security information. This security information is compiled as assertions about subjects, those subjects frequently being natural persons. These assertions, among others, are used for federated identity management, distributed authorization in general and web services in particular, and for multi-vendor portals. Fig. 2. SAML domain model [7]. Assertions are XML documents and contain information about a subject s attributes, authentication performed on the subject, and its authorizations. Using assertions, security information can be conveyed in a standardized way without requiring common authentication schemes to be agreed. Assertions are issued by SAML authorities, i.e. authentication, attribute and authorization authorities. Besides the format of an assertion, SAML defines a protocol for clients to request assertions from an authority [7]. A data/entity relationship model for SAML is provided in Fig. 2, not taking into account any actual data flow when performing SAML request/response transactions [7]. A System Entity, i.e. a subject that securely wants to access an application, will have to provide credentials first to be authenticated. This is done by an authentication authority, which issues an authentication assertion. Attribute and authorization authority will then provide respective assertions with additional information on the subject and its authorization status with respect to applications that the system entity wishes to access. When the subject performs its application request, the entity processing this request (or rather, the respective policy enforcement point) can then use the SAML assertion to verify the subject s identity, obtain relevant information that was securely disclosed in the attribute assertion, and securely authorize the application request based on the authorization assertion. 3.4. Federated service architecture The basic authorization architecture has already been presented in Section 3.1 above (Fig. 1). This section will discuss further details of federated service architectures and how SAML is applied. When the service provided by the destination site can be personalized, the service provider will maintain its own store of user information and additional criteria for authorization, such as roles and rights (Fig. 3). This will have to be synchronized (i.e. federated) with the source site s store such that they have agreed on a federated user identification

H.-J. Vögel et al. / Int. J. Electron. Commun. (AEÜ) 60 (2006) 13 19 17 Fig. 3. Personalized services. Fig. 4. Aggregator perspective. scheme linking the two stores in an unequivocal way. The Liberty Alliance approach may be used here [9]. Authorization may be distributed, such that both, the source and the destination site have control over their authorization decisions and how to enforce them. This might be coordinated in such a way that, e.g. the source site performs aggregator functions and provides basic contractual authorizations, whereas the service provider maintains service-specific personalization information on the user and the corresponding, more fine-grained, service-specific authorizations. The aggregator will be free in his choice of authentication mechanism and the credentials issued to his end users. He will maintain one single repository of credentials and the central store of user-related, frequently private information, such as address, account information, etc. Through the standardized format and protocol of SAML, the aggregator will be able to act as source site (asserting party) in a distributed authorization environment. He will be able to federate with any number of service providers and link to their service center infrastructure. This federation will happen in the same, standardized and open way, maintaining integrity of the end-user s private information while providing a secure environment to communicate identity and authorization information, among others (Fig. 4). In return the service provider will be able to sell his service through any aggregator to the respective end users. The great advantage for the service provider here is that the interface and mechanisms for identifying end users and authorizing their service requests will always be the same regardless of the aggregator. Moreover, the service provider may remain totally agnostic of the actual authentication technology used and the infrastructure in place to create an assertion. After establishing a trust relationship with the aggregator, the service provider can base his own policy enforcement decisions on the aggregator s assertion and rely on the authentication decision described therein. Perhaps most important of all, the service provider does neither have to maintain his own credential store, much less a copy of each aggregator s credential store, nor does he have to issue his own credentials to end users. This considerably reduces infrastructure requirements for service providers. 3.5. Provisioning platform requirements So far, we have directed our view more towards the upper service layers. Now, we will look closer towards the underlying networks, the corresponding service provisioning platforms and how they leverage a federation approach. A service operator (content and added value service operator) can define its own policies and policy enforcement points separating its operational domain from other operators. If the service operator does not possess own security functionalities or only parts of them, it can have agreements with one or more service provisioning platform operators (which in turn may be closely linked to the aggregator), building up security federations. Some service operators could maintain their own access network to offer their services. These

18 H.-J. Vögel et al. / Int. J. Electron. Commun. (AEÜ) 60 (2006) 13 19 access networks instantiate additional policy enforcement points that can be supported by the service operator s own policy decision points or will have to federate with a service provisioning platform operator [4]. Next-generation service-provisioning platforms accommodating above-mentioned mechanisms will be offering a number of new services, e.g. Identity services: Providing end-user identities in an open format based on the underlying network authentication will allow service infrastructure to be flexibly set up relying on an operational security infrastructure. Privacy services: By being able to make authentication and attribute assertion statements, the platform operator will be able to effectively hide the real end-user identity and hand out assertions with virtual, even service-specific identities. Multiple identities belonging to one user. Multiple authentication mechanisms. Single sign-on for multiple services and administrative domains. Multiple sessions of users using multiple devices. Distributed authorization, i.e. policies located at different administrative domains. Contracts between participating entities and federations. This will on the one hand re-define the roles in network operation, and on the other hand lead to a higher degree of flexibility when packaging services into an end user offering [4,13]. 4. Conclusion Future mobile service architectures will clearly separate technical platforms and operational roles. Service providers will define individual services of content and logic, packaged into an overall offering by a service aggregator. In turn they will rely on the services of a provisioning platform to roll out services on a number of access networks, operated by yet another business entity. This will put the necessary technical interfaces in place to have flexible decisions on the openness of the actual business policy applied. This goal is particularly well supported by the proposed federation approach. It loosely couples infrastructure security instead of relying on a monolithic, technically integrated one-size-fits-all solution. This has great advantages in particular for the inter-domain situations, when different parts of the platforms involved in serving an actual end-user application request are operated by different entities. SAML is a key enabling technology to implement those federations, standardized and supported by industry for a federated identity management system. Future telecoms will have new revenue streams by offering identity management and privacy services in this distributed infrastructure. All-in-all, they can play the role of a central trusted party for both, end-users and service providers. Aggregators and service providers already holding a customer relationship will be able to federate these contracts with network access services, to have a more integrated offering, both technically and commercially. Acknowledgement This work was partially funded by the European Commission in the projects GST and DAIDALOS of its 6th Framework Programme. References [1] Bettstetter C, Eberspächer J, Vögel HJ. GSM switching, services and protocols. Chichester: Wiley; 1999. [2] Vögel HJ. Aspects of personalization and security in an open telematics services market. Proceedings of the 10th world congress on intelligent transportation systems and services (ITS), November 2003. [3] Kühn PJ. Location-based services in mobile communication infrastructure. Int J Electron Commun (AEÜ) 2004;58: 159 64. [4] Weyl B, Brandão P, Gómez Skarmeta AF, Marin Lopez R, Mishra P, Hauser C, Ziemek H. Protecting privacy of identities in federated operator environments. Proceedings of the IST mobile summit, June 2005. [5] Kellerer W, Bettstetter C, Schwingenschlögl C, Sties P, Steinberg K-E, Vögel H-J. (Auto)mobile communication in a heterogeneous and converged world. IEEE Personal Commun Mag 2001;8:41 7. [6] Eichler S, Billion J, Maier R, Vögel HJ, Kroh R, Lonc B. On providing security for an open telematics platform. Proceedings of the ITS congress, June 2005. [7] Maler E, Mishra P, Philpott R, (Eds). Assertions and protocol for the OASIS security assertion markup language (SAML). Standard v1.1. OASIS, September 2003. [8] Cantor S, Kemp J, Philpott R, Maler E, (Eds). Assertions and protocols for the OASIS security assertion markup language (SAML). Standard v2.0. OASIS, March 2005. [9] Liberty Alliance Project webpage. http://www.projectliberty. org, 2005. [10] Internet2 Shibboleth Project webpage. http://shibboleth. internet2.edu, 2005. [11] Kaler C, Nadalin A, (Eds). Web Services Federation Language (WS-Federation). http://msdn.microsoft.com/library/default. asp?url = /library/en-us/dnglob%spec/html/ws-federation.asp, July 2003. [12] Della-Libera G, Dixon B, Farrell J, et al. Security in a web-services world: a proposed architecture and roadmap. White Paper Version 1.0. IBM Corporation and Microsoft Corporation, April 2002. [13] Aguiar R, Bijwaard D, Jähnert J, Christ P, Einsiedler H. Designing networks for the delivery of advanced flexible personal services: the Daidalos approach. Proceedings of the IST mobile summit, June 2004.

H.-J. Vögel et al. / Int. J. Electron. Commun. (AEÜ) 60 (2006) 13 19 19 Hans-Jörg Vögel received his Dipl.- Ing. and his Dr.-Ing. degree in Electrical Engineering and Information Technology from the Technische Universität München (TUM) in 1993 and 2000, respectively. At BMW Group Research, he is responsible for a research programme in the area of advanced telematics concepts, focussing on invehicle and backend IT architectures, secure remote management, service delivery platforms, and broadcast services. Dr. Vögel is currently representing BMW in the EC FP6 IST projects DAIDALOS and GST as well as some initiatives with the European Space Agency ESA and the newly founded Carto-Car Communications Consortium standardization initiative. He is a member of VDE and serves as reviewer for IEEE Communications Magazine. Stephan Eichler studied Electrical Engineering at the Braunschweig University of Technology and at the TUM. He received his Dipl.-Ing. degree in Electrical Engineering from the TUM in 2003, focussing in networking and security. Since 2003, he works as a Ph.D. candidate at the Institute of Communication Networks at TUM. He is active in the EC FP6 IST project GST. Benjamin Weyl graduated in Electrical Engineering and Information Technology at TUM in 2003. Since 2003, he is engaged in research at BMW Group Research and is pursuing a Ph.D. with the Research Group IT-Security at the Darmstadt University of Technology. He is active in the EC FP6 IST project DAIDALOS.