How Single-Sign-On Improves The Usability Of Protected Services For Geospatial Data

Transcription

1 2014 Fifth International Conference on Computing for Geospatial Research and Application How Single-Sign-On Improves The Usability Of Protected Services For Geospatial Data Andreas Matheus University of the Bundeswehr Neubiberg, Germany Abstract The Internet is full of services and data providers that offer access to massive data holdings, in particular with geospatial content. But when it comes to build meaningful applications in domains such as disaster management, what is important then? Usually trusted data and services are required. So the main questions are about open standards and technologies that allow the secure and trustworthy use of protected geospatial data and services. One prominent solution was practiced during the Group on Earth Observations (GEO) Architecture Implementation Pilot (AIP) no. 6, were international organizations from the US and Europe participated in the creation of a federation of protected data and services. During the GEO-X plenary in Geneva Switzerland in January 2014, a life demonstration concluded with the feasibility of the approach taken. It was in particular the Single-Sign-On and the managed circle of trust that enabled the creation of meaningful client applications of which one combined NASA Ames and ESA protected data. This paper reports about the resulting Access Management Federation that was implemented during AIP-6, the required standards and technologies as well as the technical approach taken. The paper concludes with findings and best practices important towards operational use. Keywords Security, Authentication, Access Management Federation, Single-Sign-On, SAML, GeoXACML, XACML, OASIS I. MOTIVATION The Internet is full of geospatial data and services. But when it comes to create meaningful applications, the use of free and open data and services is most often not sufficient. It is the trust in the data and services that becomes important. And, many providers of geospatial mapping and vector data provide view services for free but when it comes to access the vector data as an essential data asset, access to it may be restricted. Even though most geospatial data and services are interoperable because they are based on open standards, e.g. from the Open Geospatial Consortium (OGC), the interoperability of access and use of the data is broken when introducing your own security mechanism. With broken, we mean that data from protected services across different providers cannot be used in an application such as OpenLayers, because the requirement to be compliant with the specific security mechanism in place is not supported. Or, the use of the protected services becomes so extremely user unfriendly, that the use in an application is not feasible. This can happen if each protected service requests user credentials independent from another provider. To the extreme, a user must input a different username and password for each service. So, is there not a standards based solution available to improve the situation? One prominent and promising solution that is in operation around the globe for Universities and Academic institutions is called Access Management Federation (see [2]). This operational model provides all the features that are required to make use of protected data and services: (i) Single-Sign- On, (ii) Circle of Trust and (iii) Access Management. During AIP-6, an Access Management federation was created that demonstrates that it is feasible to adopt the same model from the academia for geospatial data and services. It turned out, that specific settings are required that differ from the typical setup of academic federations, but the overall organizational model remains the same. This paper aims to explain this organizational model and what the technical differences are to create an Access Management Federation for geospatial data services. The paper concludes with illustrating the power of a federation of protected geospatial data and services by developed mapping applications that run in a Web Browser (OpenLayers), as a desktop client (QGIS) and native mobile applications (Android). II. ACCESS MANAGEMENT FEDERATION AS AN ORGANIZATIONAL MODEL The term Access Management Federation (AMF) is coined in the academia: The UK Access Management Federation provides a single solution to access online resources and services for education and research (see [2]). According to the German academic federation (see [3]), the following table is a list of major academic Access Management Federations around the world. TABLE I. SELECTED LIST OF ACADEMIC AMF OF THE WORLD Europe America Asia & Australia Belnet Federation (Belgium) CAF (Canada) CARSI (China) DFN-AAI (Germany) InCommon (USA) GakuNin (Japan) Haka-Federation (Finnland) AAF (Australia) Federation Education-Recherche (France) SURFnet (The Netherlands) Entree, Kennisnet Federatie (The Netherlands) FEIDE (Norway) SWAMID (Sweden) SWITCH-AAI (Switzerland) UK AMF for Education and Research (UK and Northern Ireland) It is important to note that they all adhere to the same identical organizational model as outlined in [4]. Looking at an Access Management Federation more closely, three different roles of responsibility can be identified: Coordination Center /14 $ IEEE DOI /COM.Geo

2 (CC), Service Provider (SP) and Identity Provider (IdP) as illustrated in figure 1. Fig. 1. Federation Principle (source: [1]) The Coordination Center for a federation is in the first place responsible to manage the Circle of Trust (CoT). This involves to approve joining requests of entities that wish to participate as an IdP or SP. For either application, certain procedures are in place to ensure that the circle of trust is not breached. The coordination center also maintains, digitally signs and publishes the federation metadata which is the whitelisting of trusted entities determining the CoT; either in the role of IdP or SP. The IdP is responsible for enabling a trustworthy user management regarding the users of the organization. In particular, the organization participating as an IdP is responsible to ensure that the attributes of a user send to SPs is correct. In that sense, the user s identity is verifiable to the IdP. In addition to the user management, the IdP provides SAML compliant endpoints to support authentication requests from SPs for session initiation as well as other SAML specific protocol endpoints. And finally, an IdP must provide means and methods for login that enables the own users to provide login credentials in a secure fashion. The SP is the entity role that actually provides data sets and services. The SP does not have any user management in place. The SP relies on the IdP to report in a trustworthy manner that a user was successfully authenticated. Once an assertion about the user is received from the user s IdP, a session with the user client gets created. For each request to a protected SP endpoint, access control determines if the user characterized through the attributes sent by the IdP may execute the endpoint and receive the result. III. THE AIP-6 ACCESS MANAGEMENT FEDERATION The Group on Earth Observations (GEO) has defined a System of Systems (GEOSS) that support decision-support tools for a variety of users. In the annual initiatives called Architecture Implementation Pilot (AIP), different aspects of GEOSS for the purpose of extending / enhancing the infrastructure are practiced. During the AIP-6 initiative (March 2013 January 2014) the work in the context of data sharing focused on establishing Single-Sign-On for protected services at different participating organizations. For the federation to be established during AIP-6, two main user requirements have been considered: (i) Single-Sign-On and (ii) Social Media login. The first user focusing requirement of Single-Sign-On is key as it ensures the usability of the protected geospatial services in the first place. At this point, we need to understand that there are many potential IdPs for a user to login. Depending on the realized solution for IdP discovery, two different notions to Single-Sign-On exist. A. IdP Discovery and SSO The challenge of IdP discovery is addressed in the SAML standard in the profile called Identity Provider Discovery Profile. In order to realize this profile, it is essential do define and use the so called common domain cookie. It is therefore essential to define that common domain for the federation and to deploy a service in that domain that acts as the common domain cookie reading and writing service. This cookie contains the list of IdPs selected by the user. Based on this cookie, it is possible to remember the IdP selection which enables the optional skipping of the IdP selection. The first method of SSO is interpreted as single is associated with the number of times that a user must provide credentials (login). In most academic AMF, each session creation with a SP requires the user to select the IdP. This Single-Sign-On may be considered SSO with stop-over, as no direct (automatic) session creation is performed even though the user must not login again 1. Fig. 2. stop-over SSO As illustrated in figure 2, the list of available IdPs gets provided in a distributed fashion, e.g. by each SP individually. If not utilizing the common domain option, the decision of the IdP selection cannot be stored. Each request of the user s client to a new SP has no knowledge about any existing sessions and which IdP was used to authenticate. Therefore, the user must select the IdP. But once that has happened, the session establishment completes automatically, assuming the user has an active session with the IdP. 1 assuming the user s session with the IdP is still active 96

3 As we will see later, this stop-over is not sufficient when executing OpenLayers based web mapping applications that run inside a Web Browser. Instead, direct SSO is required which can only be achieved when the user must not select the IdP to be used when requesting a new SP session creation. How can this be achieved? For the AIP-6 federation, the common domain cookie writing service was combined with the functionality of a central Discovery Service (DS): The DS has the responsibility to provide the list of available IdPs to the user and to create and maintain the saml idp HTTP cookie. This cookie enables the direct SSO, as the selected IdP is stored in it and the selection of the IdP can be skipped when the user wishes to establish a new session with the second, third, etc. SP. Fig. 4. IdP Discovery including Trust Gateway IdP to Google OpenId As illustrated in figure 4, one of the IdPs in the AIP-6 federation acts as a mediator to the Gmail OpenId login. It is important to understand that the user credentials are not known to the gateway. It performs a clean redirect to Gmail account services, upon an authentication request is received from a SP of the federation. In order to maintain an active login session with the trusted gateway, it is required that the user selects the stay logged in option with the Gmail login. Fig. 3. direct SSO As illustrated in figure 3, the DS is the central entity that provides the list of IdPs to the user, as indicated by arrow (1). Once the user has selected his IdP as indicated with arrow (2), the DS creates the saml idp HTTP cookie and a session cookie for the application. When the user application such as the OpenLayers client is used, the JavaScript library can establish new sessions to SP 2 and SP 3 automatically, as the redirect from the DS to the IdP will not stop. However, there is one implication to the Web Browser configuration: The DS session and saml idp cookies may be considered 3rd party cookies: Assuming that the SP is hosted in domain SP.net, the IdP in IdP.org and the DS is hosted in DS.com, then the common domain is DS.com and the created HTTP cookies live in that domain. For any browser communication with the SP, were a redirect to the IdP takes place via the DS, the DS cookies are considered 3rd party. But the good thing is that only the MSIE default configuration excludes the trust of 3rd party cookies. All other major browsers support 3rd party cookies by default. If deselected, applications such as OpenLayers that need to leverage the direct SSO, will not work! B. Social Media Authentication The second user focusing requirement, to support Social Media users, was implemented in AIP-6 via a so called trust gateway from the SAML based federation to Google OpenId. This trust gateway acts as a trusted IdP towards the federation and as a OpenId consumer towards Google. Any user with a valid Gmail account is able to login via the trust gateway. IV. CLIENT APPLICATIONS In addition to the user focusing requirements, additional technical requirements can be derived from the context of application development: (i) Web Browser based applications, (ii) Desktop client applications and (iii) Mobile applications. A. OpenLayers based mapping application The support for a Web Browser based client application based on OpenLayers finalizes in constraints on allowed SSO profile / binding combinations: SAML defines exactly one profile for establishing SSO via a Web Browser: Web Browser SSO Profile. For new SP session creation, this profile leverages the ability to create a sequence of HTTP redirects. In order to actually execute the profile, one out of three bindings may be used. But only one is suitable, taking under considerations the function limitations of JavaScript enabling sessions: The HTTP Artifact Binding. This is the only suitable binding, as the SAML assertion from the IdP to the SP is passed via the secure Back-Channel. The implication for the SP configuration is that session initiation shall take place using Artifact Binding only. B. QGIS based mapping The support for desktop applications, such as QGIS, require to use a non Web Browser Single-Sign-On profile. The SAML profile named Enhanced Client or Proxy (ECP) Profile is the only one suitable, as the desktop client does not support the same functionality as a Web Browser. In particular the ability to process (X)HTML pages with JavaScript support reduce the use to this profile. It is important to note that as the name of the profile suggests SSO is not guaranteed by the profile itself. It is the client s responsibility to enable the Single-Sign-On capability by properly implementing the 97

4 Fig. 5. OpenLayers based Web Browser mapping application functionality. According to the SAML specification, the only binding option is PAOS: Reverse SOAP (PAOS) Binding. When implementing this profile and binding in a desktop application it is important to note that it is the client that indicates to the SP that it is capable of fulfilling the ECP protocol. The implication for the SP is that ECP must be supported if the provided services shall be consumed via a desktop application. The implication for the identity provider is to enable ECP if the own users that shall be able to leverage a desktop application to use protected services. Fig. 7. Android mapping application V. ACCESS MANAGEMENT, SCALABILITY AND TRUST Fig. 6. QGIS based desktop client mapping application C. Android mobile app mapping The support for mobile applications does not introduce additional technical requirements. It is important to understand that a developer of a mobile application can choose which profile to activate: Web Browser SSO Profile or Enhanced Client or Proxy (ECP) Profile. The former eases the session management but may introduce the difficulties to leverage the Web Browser application installed on the mobile device as an external application. The correlation of HTTP cookies present in the Web Browser for other applications may influence the session cookies to be maintained for federation login. It is therefore recommended that a native mobile mapping application implements ECP. In order to operate an Access Management Federation in a productive environment, it is essential to take a closer look at issues like scalability, trust and finally the ability to manage access rights. As outlined in the first chapter, the coordination center is responsible to approve requests for participation. This typically include the check of key length used to sign and encrypt SAML assertions as well as ensuring that established procedures for IdPs are sufficient for user authentication. It is also the duty of the coordination center to continuously verify that service level agreements with Service Providers and Identity Providers are met. In case of a shortcoming, the coordination center has the duty and power to exclude the entity from the federation. Regarding scalability, it is important to understand that the federation metadata does not contain the actual data service endpoints that are offered by a Service Provider or the login URL for the login at an Identity Provider. Instead, the participant provides a list of SAML specific endpoints that are characteristic for the type of participation: SP or IdP. So for example, a SP s protected WMS (e.g. /protected/service/wms) would not go into the federation metadata. Looking at productive AMF in the academia, the number of Service / Identity Providers vary from some 25 / 30 for Belnet, Belgium to 1555 / 337 for InCommon, USA. The only implication derives from IdP discovery: A simple pull-down list as used in AIP-6 is not feasible for e.g. 10 or more IdPs. But, the Discovery Service from SWITCH used in the AIP-6 work supports to store the selection in a persistent cookie. Therefore, the IdP selection must be done only once. Finally, the enforcement of Access Rights is the sole duty 98

5 of each Service Provider. Which technology / standard a service provider leverages is up to their own decision. However, it seems to be reasonable that the technology supports Attribute Based Access Control (ABAC). Why? Because the service provider receives from the IdP an assertion about the user s attributes. For the AIP-6 federation, three different nonpersonal attributes are used: 1) geoss-user, 2) affiliation and 3) unscoped-affiliation. For AIP-6 then, a Service Provider would be able to base access decisions for service and data on these user attributes. In addition, environment information such as IP addresses could also be taken under consideration. For mobile applications, the location of the device may also be taken under consideration when deriving an authorization decision. VI. STANDARDS AND TECHNOLOGY DISCUSSION Taking under consideration the introduced organizational model and the key requirement Single-Sign-On, the use of standards is actually limited to the topic of authentication. As all known Access Management Federations are based on the OASIS standard SAML (Secure Assertion Markup Language) (see [6]), it is this standard that builds the back bone of interoperability to the AIP-6 federation. At this point it is important to note that by no means it was required to implement SAML and integrate it with the existing infrastructure. The use of SAML can be reduced to deploy Web Services that support the required network endpoints to achieve interoperability for the IdP and SP. For example, the IdP can be deployed on a Tomcat, that becomes accessible via a production strength Apache Web Server. In order to enable user login, the IdP can get connected to existing user management systems such as LDAP, Kerberos, etc. For AIP-6, the simplistic use of an Apache username-password-file and LDAP was used. For the SP, the Apache or IIS Web Server configuration can be changed to load the functionality required to make the Web Service SAML authentication compliant. Once the Apache module is loaded, the Apache Web Server can be configured such that certain path require SAML based authentication. For an SP, another loosely coupled technic can also be used: Additional instance of an Apache Web Service with SAML authentication support that functions as a reverse proxy to internal services. Most, if not all productive IdPs and SPs in Access Management federations for the academia use the SAML compliant, open source software named Shibboleth. For AIP-6, the same identical main stream IT software was used to realize the AIP-6 federation. The specific requirements of session establishment and IdP discovery as outlined earlier could be realized via simple configuration options. For the sake of interoperability verification, one IdP is deployed using the former SUN product OpenAM. When it comes to the enforcement of access rights, the use of yet another OASIS standard becomes prominent: XACML (extensible Access Control Markup Language) (see [13]). The main reason for that is that XACML supports ABAC, which is the natural choice when thinking of coupling access rights with user attributes. But for the declaration and enforcement of access rights with geospatial conditions, the OGC standard GeoXACML (Geospatial XACML) (see [14]) would be a natural choice as it defines a geospatial extension to XACML: GeoXACML defines the data type Geometry and different geo-specific functions as defined in the ISO standard named Simple Features (see [15]). The use of the GeoXACML standard supports the enforcement of access rights that are based on user / mobile device location as well as the geometric characteristics (e.g. location) of protected resources. VII. CONCLUSION The major conclusion is that the AIP-6 federation for geospatial data and services can be realized using the exact same organizational model, technology and standards as the productive Access Management Federations in the academia. So beside the specific configuration of the session creation, the support for ECP and the central DS, there is nothing different. But as outlined earlier, it was entirely possible to get the AIP-6 specific settings in place by just configuring the main stream IT software Shibboleth. With the AIP-6 federation, it was possible to make protected OGC Web Services available to different kinds of clients, including a Web Browser based mapping application based on OpenLayers, a desktop GIS application such as QGIS and a simple mapping application as an Android application. For one application, protected OGC Web Coverage Service (WCS) and Web Coverage Processing Services (WCPS) for NASA Ames Research Center and ESA data sets are used. For another application, protected OGC Web Map Services (WMS) and Web Map Tile Service (WMTS) from the German Bundesamt für Kartographie und Geodäsie (BKG) and the British Catapult are used. The successful result on AIP-6 demonstrated that data sharing via the Internet among different participating organizations with Single-Sign-On support is a powerful organizational model to enable the trustworthy use of protected geospatial data and services for meaningful applications. REFERENCES [1] SWITCH, [2] Jisc, [3] DFN-AAI - Authentication and authorization infrastructure, [4] Chris Higgins, Shibboleth Access Management Federations as an Organisational Model for SDI, INSPIRE conference 2011, [5] Advancing open standards for the information society, OASIS [6] SAML: Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15 March 2005 [7] SAML-Bindings: Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15 March 2005 [8] SAML-Profiles: Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15 March 2005 [9] Internet2: Shibboleth homepage, verified on 6 January 2010: [10] Open Geospatial Consortium Inc., OpenGIS Geography Markup Language (GML) Encoding Standard, Version [11] XML Digital Signature: XML-Signature Syntax and Processing, W3C Recommendation 12 February 2002 [12] XML Encryption: XML Encryption Syntax and Processing, W3C Recommendation 10 December 2002 [13] XACML: extensible Access Control Markup Language (XACML) Version 2.0, OASIS Standard, 1 Feb 2005 [14] GeoXACML: Geospatial extensible Access Control Markup Language (GeoXACML) v1.0, Open Geospatial Consortium, Inc., 2008/02/20 [15] ISO: 19125, Geographic information Simple feature access Part 1: Common architecture 99