EDIT

# EDIT Federation

The EDIT Federation represents an implementation of the federation concept defined within the [Security Assertion Markup Language (SAML)](http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security) standards family. In the first instance, the EDIT federation is open to any members or affiliates of the EDIT project. Nevertheless, some day the EDIT federation envisions to merge into a larger (!BioDiv) federation community reflecting at minimum the most important biodiversity research institutions.

Currently, there are three membership types offered by the EDIT federation.

* registered EDIT user

* registered EDIT Service Provider (SP)

* EDIT Identity Provider(IdP)

First, registered EDIT users benefit from the enhancements of EDIT's [[CSSO|Community Single Sign-on (CSSO)]] and are enabled to use any services offered by EDIT CSSO Service Providers passing through a single login procedure only. 

Second, becoming an EDIT Service Provider (SP) mainly addresses EDIT web application or service providers who want to offer their regular users the convenience of single sign-on or those who do not want to deal with large EDIT user lists and rely on the confidentiality of the EDIT federation's user registration process. Even though, user authentication is done by EDIT's Identity Provider (IdP), EDIT Service Providers keep complete control of what users are allowed to access their services. 

This is due to the [[EDITFederationAttributes|EDIT Federation attributes]] transmitted by EDIT's IdP along with any authentication request. That way, access control may be based on these [[EDITFederationAttributes|EDIT Federation attributes]] stating e.g. the user id, group membership or roles of any authenticated EDIT user. 

Third, EDIT Identity Provider will be assigned the job to maintain a user database and to authenticate EDIT Federation users in addition to already existing IdPs within the EDIT Federation. This option may come into consideration for larger institutions managing a significant amount of (potential) EDIT users. That way, user management could be decentralised and located at the users' origin. Currently, that option is not implemented. 

Though, the remaining sections will provide some guidance on how become member of the EDIT Federation to any potential EDIT users or service providers.

For any questions, please refer to the EDIT Federation administrator (suhrbier(at)inf.fu-berlin.de).

## How to become an EDIT user ?

In order to become an registered EDIT user the following information will be requested

* valid email address

* first name, last name

* desired user id (login name)

* warrantor (name, email address) or institution stating the user's EDIT and workpackage membership

Please send these information along with an email to the EDIT Federation administrator (suhrbier(at)inf.fu-berlin.de).

After having approved these information, the EDIT Federation administrator will get back to the requestor and forward any further instructions to access the newly created account.

 *Note*::

 Please check if you have already an user account at [EDITExpertNet":http://editexpertnet.org. In that case, an EDIT user account should already be created and should be accessible by entering the same user credentials (i.e. user id and password) as at the "EDITExpertNet](http://editexpertnet.org) site.

## How to become an EDIT Service Provider ?

Initially, there are only a few basic requirements to become an EDIT Service Provider

* web application or service accessible by the http(s) protocol

* valid SSL web server certificate (X.509)

As CSSO supports the SAML web profile only, an usual web application or web service is required to be integrated within the EDIT federation. For instance, databases can not be directly connected. This is only possible if the database protocol would be encapsulated within the http protocol (e.g. web service).

For security reasons, SAML communication between CSSO infrastructure components is encrypted. Therefore, a valid SSL web server certificate is required and must be installed on the web server host.

Currently, within EDIT the most experienced setup environment consists of the following components 

* Debian/Ubuntu based server setup

* Apache2 web server

* Drupal based web application

Therefore, before setting up or developing an EDIT service, please consider the Debian/Apache web server setup environment above for your platform, as this would ease integrating EDIT Service Providers significantly.

Using Drupal is not an requirement setting up an EDIT Service Provider. In combination with the Apache2 web server, any other scenario is also welcome. Drupal's advantage is the availability of a dedicated module providing some configuration and access control facilities. 

If not using Drupal, it may be necessary to add those functions into the web application. Because, using the Shibboleth module for the Apache2 web server, the ladder only requires individual evaluation of the EDIT Federation attributes, which are available as specific web server environment variables.

If not using Apache2 web server, then at minimum PHP or J2EE is required. Then [[SimpleSAMLphp]] or OpenAM instead of the Shibboleth middleware may be an alternative option to realise EDIT Service Provider functionality. 

Finally, for those system administrator preferring to use the recommended Debian/Apache2/Shibboleth SP setup environment, a detailed installation guide and a default installation will be available at following location. 

* [[ShibbolethSP2InstallDebianLenny|Shibboleth Service Provider (SP) v2.3.x Installation on Debian Lenny]]

For any other scenario, please don't hesitate to contact me at (suhrbier(at)inf.fu-berlin.de).