Plannings of the Community Single Sign-On (CSSO) security infrastructure¶
- Plannings of the Community Single Sign-On (CSSO) security infrastructure
The Community Single Sign-On (CSSO) security infrastructure aims to integrate the security domains of various EDIT service providers into the platform. The main objective creating such security infrastructure is to recognise the requirements of many biodiverity service providers to remain the sovereigns of their resources and services offered, while enabling individual members of the EDIT community to access all these services using a single identity within the community. Also, community members have to be enregistered only once, usually at their home institution. Normally, existing identity management systems can be integrated into the security infrastructure e.g. for authentication purposes. That way, individual users have to remember one login/password combination only, but are principally enabled to access any services offered through the platform. Simultaneously, service providers may define and enforce individual access control policies in order to protect their resources or in respect to other legal or organisational constraints.
The security infrastructure being projected bases on the OASIS Security Assertion Markup Language (SAML)":http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security standard family. Besides other qualities like a secure attribute exchange framework, available open source implementations and privacy-preserving access to individually protected online resources, SAML based solutions like "Shibboleth":http://shibboleth.internet2.edu/, "Liberty Alliance Project":http://www.projectliberty.org/ or SUN's "OpenSSO":https://opensso.dev.java.net/ project excel through this federation concept versus other single sign-on(SSO) approaches like "Passport":http://www.passport.net/, "OpenID":http://openid.net/ "CAS":http://www.ja-sig.org/products/cas/ or "Kerberos
The federation concept allows for integrating various security requirements of different service providers into a common EDIT security architecture. While federated partners must agree about common policies regarding mutual acceptance of user identities, existing identification management solutions can be integrated through the SAML attribute exchange framework. Networking between all these user registries takes places through the installation of so called Identity Providers(IdP) providing user authentication at the user's home institution and attribute exchange with service providers which are accepted members of the EDIT federation. This way, the federation concept contributes to the realisation of the EDIT community aspect.
EDIT intends to provide various software components covering several aspects of taxonomic research. These components shall be offered using different technologies. Nevertheless, most of them can be assigned to one of the following use cases:
A typical web application is software program running on a web server, which is accessible over a network such as Internet oder intranet. User interaction with this software can only take place using a web browser(client). For instance, following EDIT components are examples of web applications:
Unlike web applications, a web service is a software program running on a web server delivering information in a structure data format(XML). This information is intended to be further processed by any kind of client application, which may be a web or specific desktop application or another web service as well. Web services can also be seen as network accessible APIs executing requested services on a remote system. Currently, SOAP":http://en.wikipedia.org/wiki/SOAP, "REST":http://en.wikipedia.org/wiki/REST and "XML-RPC are prominent examples for XML-based web service protocols, which may be used realising e.g. the following EDIT components:
Desktop applications (or application software) are computer programs being installed on the users's desktop computer. In contrast to web applications, desktop applications are running on a local computer and usually have an individual user interface. Nevertheless, these applications may communicate over a network with other applications like web services or databases also. If so, they are often called "rich client" as opposed to e.g. web browser, which are called "thin clients". The following EDIT components are based on those rich clients or application software:
Within EDIT, all use cases drafted above commonly rely on the standard web protocol HTTP for communication issues.
Within the SAML family, the Shibboleth protocol and middleware provides a suitable implementation of the SAML web browser profile. As such, Shibboleth provides distributed SSO authentication and authorisation for web application and web services. Herewith, Shibboleth already covers the two EDIT use cases. Since, desktop applications are designated to communicate with components of both other use cases, the CSSO security infrastructure must provide facilities to integrate desktop application into the Shibboleth framework.
On the one hand, this can be achieved providing correspondent programming interfaces to support currently developed software applications. On the other hand, this can be done through the implementation of a Shibboleth authentication proxy to integrate existing or proprietary software components as well. Since, the use cases determine desktop applications to communicate exclusively via the HTTP protocol with other components, these requirements match the facilities of the SAML web browser profile supported by Shibboleth. Therefore, such Shibboleth proxy filters outgoing connections to other, "shibbolised" EDIT components and runs the related authentication process in favour of the user running the local client software. More detailed information on how to integrate the required use cases will be presented within the Profiles section.
In a nut shell, as we have evaluated Shibboleth as a suitable framework to the EDIT requirements of a CSSO, the following paragraphs sketch the related CSSO security infrastructure. Therefore, we have to install the following basic Shibboleth components at least:
Identity Provider(s) (!IdPs)
Service Provider(s) (SPs)
As Shibboleth supports the federation concept also, the main EDIT components are likely to be grouped within an local EDIT federation. Initially, this federation comprises only one IdP and perhaps a few SPs, but may be scaled up later affiliating other institutions willing to consent to the EDIT federation policies and to manage their own IdPs and to set up further services as SPs. The former probably involves the installation of the Shibboleth WAYF (Where are you from) service, which enables users to select the institution responsible for their identification.
Finally, setting up a small Public Key Infrastructure(PKI) is necessary, because every Shibboleth components needs to be equipped with X.509 certificates in order to be authenticated and to establish secure communication channels with other components of our federation. Therefore, the PKI is only needed to issue key pairs to the providers and publish the relating certifcates e.g. via a simple LDAP directory.
Considering the use cases described earlier in this document, this section presents a detailed description on how these scenarios shall be provided using the Shibboleth framework. Therefore, the next sections elaborate profiles according to the use cases of the same name. Particularely, the web application profile comprehends a general overview of the Shibboleth integration. Both subsequent profiles are basing on the web application profile and discussing differences, options or necessary additions to it.
At first, setting up a federated security infrastructure for EDIT requires the creation of a local EDIT federation within Shibboleth. In a first approach, the EDIT federation consists of a single IdP and at least one SP, where the main focus concerning federation building is on the IdP. The ladder becomes clear realising the main tasks of an IdP such as
identity management of the EDIT federation
authentication of federation members(users)
attribute management and provision to SPs
Regarding identity management, IdPs have to manage information of any identities being member of their domains(e.g. user ids, credentials(e.g. password), real names, group/role memberships, etc.). These information have to be stored securely on the IdP's platform. Furthermore, the IdP is responsible to accurately authenticate users being members of their security domains. Therefore, the federation policies have to declare the agreed authentication methods for the EDIT federation. Next, the IdP should provide tools to ease the management of the attribute aasignment for administrators in relation with the identity management system of its security domain. Also, the IdP is responsible to securely transmit those attribute information to federated SPs requesting them e.g. during SSO authentication. Finally, IdPs should provide tools facilitating users to manage their privacy interests. That means that users should be enabled to determine the SPs to which attributes will be delivered to.
The Shibboleth middleware software itself is Open Source and can be freely installed on servlet containers like [Apache Tomcat](http://tomcat.apache.org/ running on web servers like Apache":http://httpd.apache.org/ or "IIS(Microsoft)":http://www.microsoft.com/windowsserver2003/iis/default.mspx. The middleware provides several connectors to external identity management interfaces, such as databases (e.g. MySQL) or directory services (e.g. OpenLDAP). So, existing infrastructures may be integrated or newly created. Regarding the EDIT federation, the Experts Database is considered to be integrated(see also Experts-DB integration). Other Open Source applications like "ShARPE":http://www.federation.org.au/twiki/bin/view/Federation/ShARPE, "SWITCH Group Management Tool(GMT)":http://www.switch.ch/aai/support/tools/gmt.html) or "Grouper support the administration of federations(user attributes, group/role memberships) or users' privacy concerns. It is intended to evaluate and integrate those existing solutions whenever apropriate.
The counterparts of IdPs, the SPs, are integrated by Shibboleth middleware software through provision of modules for common web servers like Apache":http://httpd.apache.org/ or "IIS(Microsoft) As service providers can configure these modules defining attributes to be requested from IdPs during authorisation, they can also assign the returned values to environment variables of the web server. This way, attributes will be transmitted to web applications running on that web server. Thus, mapping e.g. the user id attribute to the REMOTE_USER environment variable, most web applications will automatically accept that user id and granting system access to corresponding user account. Similar attribute mappings may be applied to control further application settings like e.g. role/group memberships or taxonomic interests of the given user.
Currently, an agreement on a common set of attributes within the EDIT federation is work in progress.
As web services are usually running on web servers like Apache":http://httpd.apache.org/ or "IIS(Microsoft) the same mechanisms as mentioned for web applications will also apply for web services. While common web service containers provide access to the web servers' environment variables as well, web services may be protected by Shibboleth's SSO authentication framework using the same attritues as for web applications.
Since, web service client software is usually unaware of the Shibboleth authentication framework, additional software components have to be developed to provide SSO for web services on the client level. Web service clients may either run as web services on web servers or rich clients on user desktops, the following additional components shall bridge the gap:
Due to the fact that both components apply to the desktop application profile as well, they will be discussed within the next section.
Usually, common application software is not designed tooperate with the Shibboleth authentication framework. Fortunately, the EDIT desktop application use case sketched above limits the external networking application range of those software component to the HTTP-protocol. So, those rich client software application can be integrated into Shibboleth's SSO authentication framework. To support the integration of those applications, the desktop application profile provides two additional components:
CSSO Application Programming Interface(API)
The aim of the Shibboleth Proxy is to provide an intermediate filter to the Shibboleth authentication system. This filter shall enable Shibboleth unaware applications to connect automatically and make use of HTTP-based service providers protected by the Shibboleth single sign-on authentication framework.
For that, the Shibboleth Proxy realises a user configurable HTTP proxy filter, which provides seamless access to shibbolized web service providers. For the time being, the proxy forwards any Http-request received from desktop applications to the destined service provider. Next, the proxy analyses the HTTP-response returned by the service provider. If the analysed response turns out to be a redirection request to a Shibboleth Identification Provider, the proxy takes control of the communication protocol and completely carries out the necessery authentication steps instead of by the user. When finished authentication, only the final response to its initial request is returned to the client application. This way, the Shibboleth Proxy enables any HTTP-compatible desktop application to connect to the Shibboleth SSO framework. Moreover, this can be realised without any modifications to the original software.
To subsequent client requests, the proxy adds the necessary Shibboleth identification tokens(cookies) to the HTTP-request header and forwards them to the intended destination. The required user credentials (username/password) must be provided by the user within the proxy's configuration file.
Considering the CSSO-API, the client part of the Shibboleth Proxy implementation will be provided as an programmers API to enable EDIT software developers to implement "shibbolized" client software. According to the EDIT guidelines, the Shibboleth Proxy will be developed in Java. So, the resulting CSSO-API may directly be applied within any EDIT software component to be developed.
In the first instance, the functionality of CSSO-API is limited to the initialisation of Shibboleth connection (e.g. user credential, web proxy configuration) and the handling of arbitrary HTTP-requests to Shibboleth SPs. Further functions may be added according to the needs and on request of EDIT application software developers.
Integration of further components¶
Having installed an initial Shibboleth security infrastructure for EDIT, further components shall be connected and made useable for EDIT federation memebers. At first, the software tool collection used by EDIT developers shall be attached to the Shibboleth security infrastructure. This intends to test with and get feedback from the EDIT Developers Team first, before introducing it into the whole EDIT platform. Next, starting with the integration of the Experts Database as EDIT's initial user base, further EDIT components will be integrated into the local EDIT Federation successively, depending on the maturity state of the relating software applications.
EDIT Developers Tools¶
The EDIT Developers Tools consist of the following applications
Trac integrates several developer related applications like a developer's wiki, bug tracker and read access to the developer's subversion repository within a single, web based user interface. As such, it ranks among the web application profile and it supports user authentication via the REMOTE_USER environment variable.
Subversion is a version management system, which may be hosted e.g. on an Apache web server. This way, subversion becomes not only accessible via the Http-protocol, but protectable by the Shibboleth security framework as well. As such, we could assign it the web service profile. Additionally, Subversion provides client software application running locally as desktop application accessing subversion repositories hosted on the web. Unfortunately, these client applications are not compatible with Shibboleth protocol. Therefore, the CSSO Shibboleth Proxy may be used to access subversion repositories protected by Shibboleth.
First, the following EDIT components are focussing on the integraton into the EDIT federation:
As the Experts Database shall provide the user base for the local EDIT federation, the main focus is on it.
Secondly, the focus is on attaching the Drupal content management system, as is provides the base for the integration of other EDIT related communication tools and is currently being used within the so called "!ScratchPads" of WP6.
Finally, any other EDIT components will be attached step by step as they come to maturity.
The Experts Database component developed by WP2 is intended to build up EDIT's initial user base. Beside others, one of the facilities of the Experts Database will be to take up e.g. user credentials. Additionally, the Experts Database may provide some information relevant to the Shibboleth authentication process also. Thus, those information must be made available to the attribute information base of the Shibboleth IdP component. Over and above, modifications on either information base must continuously be synchronised with the other.
In order to realise the synchronisation issue, a secure link between both components will have to be installed because some information like user credentials or group membershib attributes are very sensitive and crucial to the whole authentication process. So, from the security's vantage point, those sensitive information should only be stored on the IdP. But, using strong authentication mechanisms(e.g. certificate based secure communication, VPN tunneling) the Experts Database and IdP may synchronise those information.
Furthermore, access control related information like like user ids, passwords or group and role membership of users has to be prevented from modification by users editing their experts profile. This must only be allowed for special administrators or the users themselves using appropriate applications on the IdP host! In addition, it must be pointed out, that the IdP is one of the most vulnerable components within the whole CSSO security architecture!
Whereas other (lightweight) information like addresses, phone numbers or taxonomic interest should be left to be edited by users individually and should not be part of the user attributes approved by IdPs.
According to the timetable arranged with the current EDIT 18-month plan, the following scheme will be pursued:
June 2008 (Month 27):::
- Specification of CSSO profiles for the platform covering the use cases web application, web service and desktop application
August 2008 (Month 29):::
Setup the initial CSSO security infrastructure for the platform
Integrate the CSSO Identity Provider component with the Experts-DB
February 2009 (Month 35):::
- CSSO Security Infrastructure fully functional (Milestone)
August 2009 (Month 41):::
- Integrate further platform components with the CSSO security infrastructure