Project

General

Profile

Actions

CSSO Technical Overview



Technologically, EDIT's CSSO Security Infrastructure bases on the OASIS Security Assertion Markup Language (SAML)":http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security standard family. The main benefits of SAML include a secure attribute exchange framework, several open source implementations, privacy-preserving access to individually protected online resources and a federation concept. In particular, this federation concept perfectly matches the requirements regarding the creation of a single sign-on platform for more or less closed communities like e.g. taxonomic experts within EDIT. Beside others, the EDIT federation currently consists of about 2000 taxonomic experts registered in an SAML Identity Provider (IdP) and several SAML Service Providers (SP) instances like e.g. "EDITExpertNet Nevertheless, CSSO will integrate with other biodiversity informatics networks as well. Finally, the vision is to build up some day a CSSO infrastructure reflecting the biodiversity research community completely.

The Security Assertion Markup Language (SAML) standards family provides an architecture and defines exchange protocols for federated identity-based authentication and authorization infrastructures. A SAML federation provides part of the underlying trust required for function of the SAML architecture. A federation is a group of organizations (universities, corporations, content providers, etc.) who agree to exchange user attributes using the SAML protocols and abide by a common set of policies and practices. In so doing, they must implicitly or explicitly agree to a common set of guidelines.

Federated identity allows for information about users in one security domain to be provided to other organizations if they are member of a common federation. This allows for cross-domain single sign-on and removes the need for content providers to maintain usernames and passwords. Thereby, Identity Providers (IdPs) supply user information, while Service Providers (SPs) consume this information and gate access to secure content based on individual access control policies.

Therefore, SAML based components provide a secure framework for one organization to transmit any attributes about a web-browsing individual across security domains to another institution. In the primary usage case, when a user attempts to access a resource at a remote domain, the user's own home security domain can send certain information about that user to the service provider site in a trusted exchange. These attributes can then be used by that service to help determine whether to grant the user access to it's resource. The user may have the ability to decide whether to release specific attributes to certain sites by specifying personal Attribute Release Policies (ARP's), effectively preserving privacy while still granting access based on trusted information.

For the time being, the EDIT federation is prospected to consist of EDIT partner institutions only. A future opening towards other biodiversity institutions is envisioned. Of course, this needs political consent of EDIT federation members. Initially, federation members have to faith in each other's trustworthiness regarding their full compliance with the security policies. These policies will have to be commonly agreed. Herein, a crucial point setting up the EDIT federation concerns the set of commonly agreed attributes. Usually, this has to be commonly agreed with all federated partners. Further on, it must be ensured that attribute values are interpreted identically. Also, potential differences in user registration procedures has to be agreed. Failures within one of these fields may lead to severe security leaks, if e.g. user to group assignments or registration policies were interpreted differently or simply not respected. Further on, due to the highly distributed nature of institutions in biodiversity, the EDIT federation must remain independent from individual or national authentication and authorisation infrastructures (AAIs) like e.g. DFN-AAI (Germany).

Currently, the common set of attributes for the EDIT federation is oriented towards integrating Cybertaxonomy platform components. So, only those attributes which are required within web applications for user authentication (e.g. login id, groups/roles), user communication (e.g. email address) or editing user profile information (e.g. name) are included. In addition, each user gets an unique identity identifier which will not change during system lifetime. That way, identities can be recognised even they are changing e.g. their institution and/or login id. Current attribute names in EDIT have been oriented towards the eduPerson schema, which is often recommended as starting point for higher education environments.

As most of SAML based single sign-on infrastructures, CSSO must include at least one Identity Provider (IdP) and one Service Provider (SP) component. The following section will describe those components implemented in CSSO.

Identity Provider (IdP)

At the heart of any SAML federation lies the Identity Provider. It authenticates users and supplies service providers with attributes about authenticated users.

Within the EDIT federation, the Identity Provider's role includes the following tasks

  • identity management of the EDIT federation

  • authentication of EDIT users

  • attribute management and provision to SPs

  • privacy protection

Regarding identity management, IdPs have to manage information of all identities being member of its domains (e.g. institutions). Identity information may include attributes like user ids, credentials (e.g. password), real names or group/role memberships. This information has to be gathered accurately according to the federation's security policies and stored on the IdP's platform in a secure manner. Furthermore, the IdP is responsible to authenticate any users belonging to its security domain. The authentication methods have to be commonly agreed within the federation policies.

Next, the IdP should provide tools to ease the management of the attribute assignment for administrators in relation with the identity management system of its security domain. Also, during SSO authentication, the IdP has to securely transmit attribute information of the given user on request from federated Service Providers (SPs). Finally, IdPs should provide tools facilitating users to manage their private data. That may include that users should be enabled to determine the pieces of information released to Service Providers (SPs).

Within EDIT, OpenSSO has been evaluated as suitable Identity Provider software. OpenSSO supports the SAML's Single Logout (SLO) feature and includes some user management and user profile functionalities. As meanwhile, OpenSSO's community version has moved to OpenAM, EDIT will move to OpenAM too when upgrading to the next release. For EDIT system administrators, we provide detailed OpenAM(OpenSSO) installation instructions on Debian Lenny.

Usually, Shibboleth would be the first choice IdP implementation. Unfortunately, Shibboleth has currently no SLO support. User management must be done externally, but Shibboleth supports most common standard interfaces to databases (SQL), directory services (LDAP) or files.

Another option to implement IdP services is SimpleSAMLphp, which is the first choice solution within PHP only web environments like hosted web space.

Service Provider (SP)

Service providers grant access to their web resources based on attributes requested from a federated Identity Provider (IdP). Initially, users requesting access to a Service Provider's resources will be redirected to the Identity Provider (IdP) of their home institution. If a federation included multiple Identity Providers (IdP), then users would have to determine the Identity Provider (IdP) of their home institution via the Discovery Service (DS) first.

After having logged in successfully at their home IdP, users receive a secure token and will be redirected back to the initially requested SP resource. Once, a user received that token, it will be cached in his browser and can be presented to any SP in order to access its web resources. The secure token permits SPs to retrieve any attributes released for the user presenting it.

Finally, the SP verifies the validity of the secure token (e.g. by requesting the user's home IdP) and grants or denies access to the requested resource. The last step will be executed after having validated the user attributes against the SP's local access control policies. The following diagram shows the authentication processing.

[!CSSO-Flowpng|768px!]

Regarding Service Providers, the most recommended and experienced software implemented in EDIT is Shibboleth. Shibboleth is a module for the Apache web server and thus requires its installation. Please find more detailed installation instructions in the following document: EDIT Service Provider installation instructions for Debian Lenny.

Like for IdP services, SimpleSAMLphp is a recommended alternative for PHP only web environments like hosted web spaces. OpenSSO may be used for J2EE only based environments.

Technically, a Service Provider is an entity that provides a web-based service, application, or resource subject to access control by a SAML federation. So called "applications" are the primary unit of SP configuration. An individual application represents a set of web resources that operates using the same attribute handling and trust configuration and shares a common session with the browser user. As a user navigates between resources on a server that cross an application boundary, a new session is established, though user interaction may not be required. As a consequence of the relationship between applications and sessions (which are tracked with a cookie), an application usually does not span more than one virtual host. Apart from cookie-based constraints, web resources can be aggregated into applications in arbitrary ways.

Much of an Service Provider implementation is concerned with establishing, and subsequently maintaining, sessions with the browser user on behalf of the applications located at the Service Provider. A session consists of a cookie passed between the browser and web server, associated with a security context. The context contains the user's authentication information, and generally a set of attributes that make up the user's identity. Each application maintains distinct sessions with the browser by means of separate cookies. It is important to note that all such sessions are independent and distinct: any session can exist with or without any other session, and the expiration of any one session does not imply the expiration of any other session.

Discovery Service (DS)

If there is more than one Identity Provider (IdP) in a federation, users will be redirected to a Discovery Service (DS). The only task of a DS is to redirect users to their home institution's IdP for authentication. Users just have to select their home IdP from a list of federated IdPs presented in their browsers. If, like at the current EDIT Federation, a federation consists of one IdP only, the implementation of a DS is not necessary.

Suitable Discovery Service implementations are offered by either Shibboleth, SimpleSAMLphp or OpenSSO.

Public Key Infrastructure (PKI)

In order to enable secure communication between the components of the CSSO security infrastructure, all components need to be equipped with X.509 certificates. Due to the Invalid Security Certificate Problem, IdP and SP administrators should purchase certificates issued by one of the recognised Certification Authority (CA), which come preinstalled in most common web browsers. For instance, in Germany the PKI of the Deutsche Forschungsnetzwerk (DFN-PKI) offers such certificates free for public sector institutions. Recently, IdPs and SPs belonging to the EDIT domain (e-taxonomy.eu) could have equipped with certificates issued by DFN-PKI via the Freie Universität Berlin (FUB-CA) Certification Authority.

Formerly, the EDIT Federation used its own Certification Authority, but raising the Invalid Security Certificate Problem due to the usage of self-generated certificates. Nevertheless, this Certification Authority may be used for test or demo purposes, or to generate certificates for interim use.

Updated by Andreas Müller almost 2 years ago · 26 revisions