Shibboleth Identity Provider (IdP) Setup on Debian Etch¶
- Table of contents
- Shibboleth Identity Provider (IdP) Setup on Debian Etch
IdP Software Installation¶
The current installation uses the Shibboleth Identity Provider (IdP) version 1.3.2. The IdP implementation bases on Java Servlets. Therefore, we need a servlet container like Tomcat and a Java Virtual Machine like SUN JDK5. The authentication shall be controlled by the Apache Web Server. So, before installing the IdP, we decided to install
SUN JDK5
Apache Tomcat 5.5
Apache Web Server 2.2
SUN JDK5 Installation¶
In order to install Tomcat, a Java virtual machine like SUN JDK5 must be installed first.
Please refer to the description SUN JDK5 Installation on Debian Etch
Apache Tomcat 5.5 Installation¶
Having installed Java, we just need to install the tomcat5.5 package:
# apt-get install tomcat5.5
Because the IdP-servlet needs access to the file system, we must turn off Tomcat security in /etc/default/tomcat5.5:
TOMCAT5_SECURITY=no
Apache Web Server 2.2 Installation¶
Beside the Apache Web Server, we need the Apache module mod_jk enabling the Apache Web Server to work in front of Apache Tomcat:
# apt-get install apache2 libapache2-mod-jk libapache-mod-jk-doc
To start the Apache Web Server at boot time, edit /etc/default/apache2 and set NO_START=0:
# 0 = start on boot; 1 = don't start on boot NO_START=0
Authentication relies on https. So, we must enable the Apache Module ssl and restart the Apache Web Server.
# a2enmod ssl # /etc/init.d/apache2 restart
Shibboleth IdP Installation¶
Having done all preliminaries described above, the current version of the Shibboleth IdP (1.3.2) can be downloaded from http://shibboleth.internet2.edu/downloads/. The IdP installation script requires the Ant packages and the the JAVA_HOME variable should be set correctly. Extracting the downloaded IdP software and running the ant command within the resulting directory starts the IdP's setup routine.
# wget http://shibboleth.internet2.edu/downloads/shibboleth-idp-1.3.2.tar.gz # tar xvfz shibboleth-idp-1.3.2.tar.gz # apt-get install ant # echo $JAVA_HOME # cd shibboleth-1.3.2-install # ./ant
Answer all question with the default value (), except the question for the Tomcat home directory, which is /var/lib/tomcat5.5
Enter tomcat home directory [default: /usr/local/tomcat] /var/lib/tomcat5.5
This should have installed the Idp to /usr/local/shibboleth-idp/ and the Idp servlet should appear into /var/lib/tomcat5.5/webapps
# ls /var/lib/tomcat5.5/webapps shibboleth-idp.war
Now, some access rights should be adepted for tomcat55.
This seems to be an important step to run the IdP!
# chown tomcat55 /usr/local/shibboleth-idp/logs # chmod 755 /usr/local/shibboleth-idp/bin/*
After restarting Apache & Tomcat a directory named shibboleth-idp should appear within ::/var/lib/tomcat5.5/webapps/_.
# /etc/init.d/apache2 restart;/etc/init.d/tomcat5.5 restart # ls /var/lib/tomcat5.5/webapps shibboleth-idp shibboleth-idp.war
Configure SSL¶
First, install the necessary packages, where the ca-certifcates package is optional.
# apt-get install openssl ca-certificates
Then, if you want to check your installation later against the Shibboleth test service, then copy the certificate and key obtained during the registration process of your IdP to /etc/ssl/certs/testshib.crt or /etc/ssl/private/testshib.key respectively.
Shibboleth runs as Tomcat container, therefore Tomcat needs access rights to read certificate and key from the ssl directories.
First, create a group called ssl and add the user tomcat55. Then set appropriate access rights to the directories.
# addgroup ssl # adduser tomcat55 ssl # chown -R root:ssl /etc/ssl/certs # chown -R root:ssl /etc/ssl/private # chmod 740 /etc/ssl/certs/* # chmod 740 /etc/ssl/private/* # chmod 750 /etc/ssl/certs # chmod 750 /etc/ssl/private
If you want to create your own keys and certificates, copy them to the mentioned directories and set the access rights as described above.
Don't forget to adapt the paths to the files in your Apache and Shibboleth configuration as well !
Create Keys and Certificates with OpenSSL¶
Generate an SSL-Key for the server.
# openssl req -new -x509 -nodes -out /etc/ssl/certs/idp.e-taxonomy.eu-cert.pem -keyout /etc/ssl/private/idp.e-taxonomy.eu-key.pem
See http://wiki.ubuntuusers.de/Apache/modssl for more info.
IdP Configuration¶
The IdP has to perform following two main tasks:
Authentication of users (using port 443) and token generation
Deliver user attributes requested by Shibboleth Service Providers(SP) (using port 8443)
Since all requests are received by the Apache Web Server first, it is responsible as well for user authentication as for redirecting requests on ports 443 and 8443 to the related servlets running on the Apache Tomcat.
In all our configuration examples, we admit that the IdP is located on idp.e-taxonomy.eu. So, you have to change this in order to run your own IdP instance.
First, we want to configure an IdP instance and test its basic functionality against the Shibboleth test service. Further configuration scenarios may follow...
Apache Web Server Configuration¶
All requests to the Idp will be addressed in the form https://idp.e-taxonomy.eu/shibboleth-idp/.... Apache has to redirect these request to the IdP-servlet running on Tomcat. This will be done by configuring the module mod_jk, and authentication and authorisation system on the Apache Web Server properly.
The necessary configuration steps for the Apache Web Server may be spreaded into several files such as /etc/apache2/modules-available/jk.conf, /etc/apache2/ports.conf, /etc/apache2/sites-availabe/idp-authentication and /etc/apache2/sites-availabe/idp-autorisation. For simplificity, we recommend to get them all together in the file /etc/apache2/conf.d/idp.conf.
Configuring Module mod_jk¶
The module mod_jk has to be configured within the file /etc/libapache2-mod-jk/workers.properties, where the following entries in /etc/libapache2-mod-jk/workers.properties should be adepted as follows:
workers.tomcat_home=/usr/share/tomcat5.5 workers.java_home=/usr/lib/jdk ps=/ worker.list=ajp13_worker worker.ajp13_worker.type=ajp13 worker.ajp13_worker.host=localhost worker.ajp13_worker.port=8009
The module's configuration within Apache could be stored within /etc/apache2/modules-available/jk.conf_or being part of the single configuration file in _/etc/apache2/conf.d/idp.conf:
JkWorkersFile /etc/libapache2-mod-jk/workers.properties JkShmFile /var/run/apache2/jk-runtime-status JkLogFile /var/log/apache2/mod_jk.log JkLogLevel info JkMount /shibboleth-idp/* ajp13_worker
Configuring the authentication system¶
For testing, a suitable key/certificate pair must be available. This can be done registering at The Open Identity Provider as recommended by the Shibboleth test service. After succesful registration you will get an login at the Shibboleth test service and can register new identity or service provider.
During this process, you have to enter the to enter the domain (e.g. e-taxonomy.eu) and the complete host name (e.g. idp.e-taxonomy.eu) of your identity provider. Finally, a correspondent key pair will be generated, which you should store in your system.
The key file (e.g. testshib.key) should be stored within the directory /etc/ssl/private and the certificate (e.g. testshib.crt) in the directory /etc/ssl/certs. Ensure, that these files are readably by the users www-data (for Apache Web Server) and tomcat55 (for Apache Tomcat). If something does not work, may be that's the reason!
Let's configure an authentication system
listening on port 443
defining a virtual host for the IdP host
defining basic authentication for the Shibboleth SSO location (/shibboleth-idp/SSO)
# Authencation system (/shibboleth-idp/SSO) Listen 443 # replace 'idp.e-taxonomy.eu' with the host name of your IdP <VirtualHost idp.e-taxonomy.eu:443> ServerName idp.e-taxonomy.eu SSLEngine on SSLCertificateFile /etc/ssl/certs/testshib.crt SSLCertificateKeyFile /etc/ssl/private/testshib.key # Apache Authentication using a simple user data base <Location /shibboleth-idp/SSO> AuthName "Cyber Taxonomy Identity Provider" AuthType Basic AuthUserFile /etc/apache2/user.db require valid-user </Location> </VirtualHost>
Simple user database authentication¶
For basic tests, it is adequate just to to create some test users in an Apache user data base /etc/apache2/conf.d/user.db:
# htpasswd -c /etc/apache2/user.db testuser # htpasswd /etc/apache2/user.db testuser2
Authentication against MySQL database¶
A more complex scenario is to authenticate users against a MySQL database. Therefore, we would need the Apache2 module auth-mysql, which is currently not maintained and therefore not part of the Debian stable release.
For instance, the IdP shall authenticate users against a MySQL database. The basic installation steps are described here:
Authentication against LDAP via PAM¶
TODO
Configuring the authorisation system¶
Finally, let's configure the authorisation system
listening on port 8443
defining a virtual host for the IdP host on port 8443
defining basic authentication for the Shibboleth location (/shibboleth-idp/AA)
Here, we have to use the same key pair as configured for the authentication system. So, this part of the configuration is straight forward
# Authorisationssystem (/shibboleth-idp/AA) Listen 8443 # replace 'idp.e-taxonomy.eu' with the host name of your IdP <VirtualHost idp.e-taxonomy.eu:8443> ServerName idp.e-taxonomy.eu SSLEngine on SSLCertificateFile /etc/ssl/certs/testshib.crt SSLCertificateKeyFile /etc/ssl/private/testshib.key <Location /shibboleth-idp/AA> SSLOptions +StdEnvVars +ExportCertData </Location> </VirtualHost>
Restart Apache:
# /etc/init.d/apache2 restart
Now, using your browser send a request to https://idp.e-taxonomy.eu/shibboleth-idp/SSO. You should be requested to enter a username/password from the configured user database. You should receive an error page (IdP servlet not found) from +Apache Tomcat+ after succesful authentication.
Apache Tomcat Configuration¶
Regarding Tomcat, we just want to turn off its own authentication mechanism and to ensure, that Tomcat listens for local requests (from the Apache Web Server) only.
Edit /usr/share/tomcat5.5/conf/server.xml and add the following properties to the Connector for port 8009:
request.tomcatAuthentication="false" address="127.0.0.1"
It should look like this:
<!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" request.tomcatAuthentication="false" address="127.0.0.1" />
Restart Apache and Tomcat:
# /etc/init.d/apache2 restart # /etc/init.d/tomcat5.5 restart
Accessing https://idp.e-taxonomy.eu/shibboleth-idp/IdP.jsp should now return an Shibboleth Identity Provider Failure.
Configuring the IdP for testing against TestShib¶
You can find all the following steps on the TestShib configuration page But here, the steps are adepted to our needs.
Shibboleth's default configuration directory is /usr/local/shibboleth-idp/etc/.
First, backup the default configuration file.
Next, we should download and extract the configuration files prepared by TestShib to the default configuration directory:
# wget http://www.testshib.org/config/java/testshib-idp-config.tar # tar xfv testshib-idp-config.tar -C /usr/local/shibboleth-idp/etc
Now, we edit /usr/local/shibboleth-idp/etc/idp.xml and
Change the providerId value of the element to match the one you're using with TestShib (https://idp.e-taxonomy.eu/shibboleth/testshib/idp)
Change the and subelements to match the location of the downloaded key and certificate files from TestShib (file:/etc/ssl/private/testshib.key and file:/etc/ssl/certs/testshib.crt)
For debugging. you should change the log levels in the element to "DEBUG".
Should look like this:
<IdPConfig xmlns="urn:mace:shibboleth:idp:config:1.0" xmlns:cred="urn:mace:shibboleth:credentials:1.0" xmlns:name="urn:mace:shibboleth:namemapper:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:idp:config:1.0 ../schemas/shibboleth-idpconfig-1.0.xsd" AAUrl="http://idp.example.org:8080/shibboleth-idp/AA" resolverConfig="file:/usr/local/shibboleth-idp/etc/resolver.xml" defaultRelyingParty="urn:mace:shibboleth:testshib" providerId="https://idp.e-taxonomy.eu/shibboleth/testshib/idp"> ... <Logging> <ErrorLog level="DEBUG" location="file:/usr/local/shibboleth-idp/logs/shib-error.log" /> <TransactionLog level="DEBUG" location="file:/usr/local/shibboleth-idp/logs/shib-access.log" /> </Logging> ... <Credentials xmlns="urn:mace:shibboleth:credentials:1.0"> <FileResolver Id="testshib_creds"> <Key> <Path>file:/etc/ssl/private/testshib.key</Path> </Key> <Certificate> <Path>file:/etc/ssl/certs/testshib.crt</Path> </Certificate> </FileResolver> </Credentials>
In the file /usr/local/shibboleth-idp/etc/resolver.xml, change the smartScope attributes to match your domain (e-taxonomy.eu).
<!-- To use these attributes, you should change the smartScope value to match your site's domain name. --> <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" smartScope="e-taxonomy.eu"> <AttributeDependency requires="urn:mace:dir:attribute-def:eduPersonAffiliation"/> </SimpleAttributeDefinition> <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrincipalName" smartScope="e-taxonomy.eu"> <DataConnectorDependency requires="echo"/> </SimpleAttributeDefinition>
You may download a fresh copy of the metadata from http://www.testshib.org/metadata/testshib-metadata.xml and put it in the default configuration directory (/usr/local/shibboleth-idp/etc/), if you'll be testing against other TestShib members.
Test the provider¶
To test your configuration, access https://sp.testshib.org/ and enter your providerId(https://idp.e-taxonomy.eu/shibboleth/testshib/idp) into the related text field.
Next, authenticate to your provider as one of the users you created. The sample service provider will display all attributes that this identity provider is configured to release to this resource. These will differ depending on the configuration and whether the echo responder or a directory/database is used.
Done.
Configuring the IdP for a local EDIT federation¶
First, you should generate a key pair (certificate) for your IdP, copy the files to their appropriate location and set the access rights properly as described in the Configure SSL section. We used the following file names:
Certificate: /etc/ssl/certs/idp.e-taxonomy.eu-cert.pem
Key : /etc/ssl/private/idp.e-taxonomy.eu-key.pem
Configuring Apache¶
Next, change the values for SSLCertificateFile and SSLCertificateKeyFile within the Apache configuration to the values above as described for the authentication system and for the authorisation system.
Install Java ODBC Driver for MySQL¶
Since we are using MySQL to retrieve usernames and user attributes, we have to install the Java ODBC driver for MySQL. To enables Tomcat for using the driver libraries, we set a link to the library in Tomcats shared library directory.
# apt-get install libmysql-java # ln -s /usr/share/java/mysql.jar /var/lib/tomcat5.5/shared/lib/
Configuring the IdP¶
After this, we configure the IdP as part of the EDIT federation, adapting the file /usr/local/shibboleth-idp/etc/idp.xml. Compared to version generated within the TestShib configuration section, the following entries may be subject of change:
AAUrl::
The IdP handles attribute request on this URL: "http://idp.e-taxonomy.eu:8443/shibboleth-idp/AA".
defaultRelyingParty::
This is our EDIT federation now. We defined the URI "https://shibboleth.e-taxonomy.eu/Federation" to be used as its entity identifier.
providerId::
The providerId is now "https://idp.e-taxonomy.eu/shibboleth-idp"
!RelyingParty::
We define that the EDIT federation uses the credentials named idp_creds to sign attribute statements and requests.
Credentials::
Within the credentials elements, we define where to find the credentials for the id idp_creds, and adapt the paths for key and certificate files as described earlier.
file:/etc/ssl/private/idp.e-taxonomy.eu-key.pem (Key)
file:/etc/ssl/certs/idp.e-taxonomy.eu-key.pem (Certificate)
If the key file is protected by a password, then you can add the attribute password="secret to the credentials Key element.
!MetadataProvider::
Adapt the path to the metadata file for the EDIT federation in the uri attribute (uri="file:/usr/local/shibboleth-idp/etc/EDIT-Federation-metadata.xml")
Should look like this
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- Shibboleth Identity Provider configuration --> <IdPConfig xmlns="urn:mace:shibboleth:idp:config:1.0" xmlns:cred="urn:mace:shibboleth:credentials:1.0" xmlns:name="urn:mace:shibboleth:namemapper:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:idp:config:1.0 ../schemas/shibboleth-idpconfig-1.0.xsd" AAUrl="http://idp.e-taxonomy.eu:8443/shibboleth-idp/AA" resolverConfig="file:/usr/local/shibboleth-idp/etc/resolver.xml" defaultRelyingParty="https://shibboleth.e-taxonomy.eu/Federation" providerId="https://idp.e-taxonomy.eu/shibboleth-idp"> <RelyingParty name="https://shibboleth.e-taxonomy.eu/Federation" signingCredential="idp_creds"> <NameID nameMapping="shm"/> </RelyingParty> <ReleasePolicyEngine> <ArpRepository implementation="edu.internet2.middleware.shibboleth.aa.arp.provider.FileSystemArpRepository"> <Path>file:/usr/local/shibboleth-idp/etc/arps/</Path> </ArpRepository> </ReleasePolicyEngine> <Logging> <ErrorLog level="DEBUG" location="file:/usr/local/shibboleth-idp/logs/shib-error.log" /> <TransactionLog level="DEBUG" location="file:/usr/local/shibboleth-idp/logs/shib-access.log" /> </Logging> <NameMapping xmlns="urn:mace:shibboleth:namemapper:1.0" id="shm" format="urn:mace:shibboleth:1.0:nameIdentifier" type="SharedMemoryShibHandle" handleTTL="28800"/> <ArtifactMapper implementation="edu.internet2.middleware.shibboleth.artifact.provider.MemoryArtifactMapper" /> <Credentials xmlns="urn:mace:shibboleth:credentials:1.0"> <FileResolver Id="idp_creds"> <Key password="secret"> <Path>file:/etc/ssl/private/idp.e-taxonomy.eu-key.pem</Path> </Key> <Certificate> <Path>file:/etc/ssl/certs/idp.e-taxonomy.eu-cert.pem</Path> </Certificate> </FileResolver> </Credentials> <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.ShibbolethV1SSOHandler"> <Location>https?://[^:/]+(:(443|80))?/shibboleth-idp/SSO</Location> </ProtocolHandler> <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_AttributeQueryHandler"> <Location>.+:8443/shibboleth-idp/AA</Location> </ProtocolHandler> <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_1ArtifactQueryHandler"> <Location>.+:8443/shibboleth-idp/Artifact</Location> </ProtocolHandler> <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.Shibboleth_StatusHandler"> <Location>https://[^:/]+(:443)?/shibboleth-idp/Status</Location> </ProtocolHandler> <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata" uri="file:/usr/local/shibboleth-idp/etc/EDIT-Federation-metadata.xml"/> </IdPConfig>
Resolve attributes¶
Within the Resolver configuration file(/usr/local/shibboleth-idp/etc/resolver.xml), we configure how to retrieve attribute values requested by service providers. Currently, we are using a MySQL database to store these values. Therefore, the JDBCDataConnector element is configured which URL and driver to use. Additionally, a SQL query statement must be defined to retrieve the named attributes from the database. The attributes and their names in the MySQL database are defined in the SimpleAttributeDefinition elements.
<AttributeResolver xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mace:shibboleth:resolver:1.0" xsi:schemaLocation="urn:mace:shibboleth:resolver:1.0 shibboleth-resolver-1.0.xsd"> <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:uid" sourceName="uid"> <DataConnectorDependency requires="userDB"/> </SimpleAttributeDefinition> <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:mail" sourceName="mail"> <DataConnectorDependency requires="userDB"/> </SimpleAttributeDefinition> <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrincipalName" sourceName="name"> <DataConnectorDependency requires="userDB"/> </SimpleAttributeDefinition> <JDBCDataConnector id="userDB" dbURL="jdbc:mysql://160.45.63.30:3306/drupal5?user=webuser" dbDriver="com.mysql.jdbc.Driver" maxActive="10" maxIdle="5"> <Query>select uid, name, mail from drupal5._shared_users where name = ?</Query> </JDBCDataConnector> </AttributeResolver>
Within the the Attribute Release policy configuration file(/usr/local/shibboleth-idp/etc/arps/arp.site.xml), we can configure which attributes are offered to different sites. With the following version, you deliver the stated attributes to any site:
<?xml version="1.0" encoding="UTF-8"?> <AttributeReleasePolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mace:shibboleth:arp:1.0" xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd" > <Description>Simplest possible ARP.</Description> <Rule> <Target> <AnyTarget/> </Target> <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName"> <AnyValue release="permit"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation"> <AnyValue release="permit"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"> <AnyValue release="permit"/> </Attribute> <Attribute name="urn:mace:dir:attribute-def:mail"> <AnyValue release="permit"/> </Attribute> </Rule> </AttributeReleasePolicy>
This can be restricted for definable values and sites. Using specific files for every registered user, every user can self-determine, which attributes were delivered to which site.
Testing the resolver configuration¶
You may test the resolver configuration with the resolvertest tool. If it works, then you should the all attributes retrieved from the database.
export IDP_HOME=/usr/local/shibboleth-idp export CLASSPATH=$CLASSPATH:/usr/share/java/mysql.jar $IDP_HOME/bin/resolvertest --user=user_id --file=file:///$IDP_HOME/etc/resolver.xml
In order to use it, you must extend the Java classpath to the location of the ODBC MySQL driver installed earlier.
Define the federation's meta-data¶
Last but not least, we define our federation within the MetaDataProvider, which in our case is located in the file /usr/local/shibboleth-idp/etc/EDIT-Federation-metadata.xml
<?xml version="1.0" encoding="UTF-8"?> <md:EntitiesDescriptor Name="https://shibboleth.e-taxonomy.eu/Federation" validUntil="2010-01-01T00:00:00.000Z" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <EntityDescriptor entityID="https://idp.e-taxonomy.eu/shibboleth-idp" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <KeyDescriptor use="signing" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> MIIGoDCCBIigAwIBAgIBBTANBgkqhkiG9w0BAQUFADCBgTELMAkGA1UEBhMCRVUx DTALBgNVBAoTBEVESVQxDzANBgNVBAsTBldQIDUuNzEoMCYGA1UEAxQfU2VydmVy Q0EgPHNlY3VyZS5lLXRheG9ub215LmV1PjEoMCYGCSqGSIb3DQEJARYZc3VocmJp ZXJAaW5mLmZ1LWJlcmxpbi5kZTAeFw0wNzA4MTQxNDI2MDNaFw0xMjA4MTIxNDI2 MDNaMEkxCzAJBgNVBAYTAkVVMQ0wCwYDVQQKEwRFRElUMQ8wDQYDVQQLEwZXUCA1 LjcxGjAYBgNVBAMTEWlkcC5lLXRheG9ub215LmV1MIICIjANBgkqhkiG9w0BAQEF AAOCAg8AMIICCgKCAgEAyYGG3QDpZSc7/9JSzV1y4RL4+CtbhKDhaBu951xpNQnZ m1lMl9Xa7iJAtUdF0OrwgOVZTqrMQAW6ozan9kIxs+CH8vaGDVOwoakYh5Sa8jAG ZlhxxAF+ivkc1I9O9kBbYUs0rIkGRGgOnp8bSoekxqtUrcSRH+L5MWiF3BYnGqry 3Q5VsrGU7gI1aDPLbJPBV/5eVCurP51ETuS/hLc94PH6McAxl1hfrBkprL3SqtoE eIaobIlMFWItMwKLBN0S5hxOdB517gsGhzj8RtuVLEbJ1P3UnOcZ+t6qzZDKBlFD +cx8EG2LQHig9ZqEF7aXBFeIw16Hcpcd1/yzv4KInhZig8aHnUwDjAihYy6PomPf YACF6GQGCVns+yPeC8CAlNNjei+xItY8VjOGzRtbBP2i6nNQuhjbZ33IuXKvOUKi q/mNuppqgFV1M672vvGYJns2l7yx/XMKml0jo83ChpEp5aWfHJfJ66Mo5Vca+hnF dozklIP9rXD/37pvuJp3T13v8ZZnafjvJ206TVx7VkTS/dTP1vsHayKSLU0jVP88 NoYzNK1fwiAh4frU7xQIcbTCF7s084ZAGrLeWXdfYHa/LlQgH/XH6/hA+n1DqjQr i2+vrPZ46bAomYZwzuznjG7mM1PAZqGuPFAzfAuP2m++4GTf20mO+uIlKT/kUK8C AwEAAaOCAVgwggFUMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgbAMCsGCWCG SAGG+EIBDQQeFhxUaW55Q0EgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW BBQDgm8huZWg9FSa9PZTy8obfgeEHTCBoAYDVR0jBIGYMIGVgBRN9+1IWVSEJR/3 b1JY6166vOHcZ6F6pHgwdjELMAkGA1UEBhMCRVUxDTALBgNVBAoTBEVESVQxDzAN BgNVBAsTBldQIDUuNzEdMBsGA1UEAxMUc2VjdXJlLmUtdGF4b25vbXkuZXUxKDAm BgkqhkiG9w0BCQEWGXN1aHJiaWVyQGluZi5mdS1iZXJsaW4uZGWCAQEwJAYDVR0S BB0wG4EZc3VocmJpZXJAaW5mLmZ1LWJlcmxpbi5kZTAPBgNVHREECDAGhwSgLT8V MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAgEAPquo66iULZPmlz1o K9L4KX+cehtL1bbFKv9XqMV050tqurkRr9+mIOO1mFye6zZ9RNs40yw1n4+gEVnj x6y9JkGuwkhz9E+Wy+EU4NMVWuWkwnSTBKoDEPf6Copvu7+6bAlW+HUJAFj5Thr3 YNgOKnl9tnl6yKZL6htDuKN+aXKeMh8JdoPEy5YNy+b8nrC7xEAvRwnV1aq2ca9K Pq7H48fU/rPahdiYPeZqdLAbKTH0nmYU+fa0868UVjMmfoibfyObIX7xVyNyCiC5 Xcd8CbnDdIvWl3/3ZTmrHvJzsLPQQidLR7Ak9ujo7yXPu0WW3HlvyriFwwKUOVlL 81XNqlCfEWVs7b8gfOZmrLndUEqH6Y7uFcoVNCOCOr0D+Uq7FL3QJF7wKnwikpgw Lqn8tmFoMr0MTmLOYMfKy+u5Xvw6O5LYBS42sJjn1CfiQbrriIUL4JNgo3efsU0d M+ivcekSRCMFTGU60C3w+sD8HMn26uy/en4sTaDRsxXyPe7GxJsG42WGUK6oddRF XXg7cQZ3u3YwttvV8eelgFXP9hvyk0JxwGkxOlIQx5e7ibQTLwshRVFZ83pBCD8n hPDDISO8yvSJuBPJUrp6Y74ATl6VcalKCV3PsC9/ZAdLKNOrG9L8I1ut9MNE64sz 7BOrHuNQuTlOQhxvxa22Mwl4C0M= </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.e-taxonomy.eu/shibboleth-idp:8443/shibboleth-idp/Artifact" index="1" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> <NameIDFormat xmlns="urn:oasis:names:tc:SAML:2.0:metadata">urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://idp.e-taxonomy.eu/shibboleth-idp/shibboleth-idp/SSO" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> </IDPSSODescriptor> <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <KeyDescriptor use="signing" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> MIIGoDCCBIigAwIBAgIBBTANBgkqhkiG9w0BAQUFADCBgTELMAkGA1UEBhMCRVUx DTALBgNVBAoTBEVESVQxDzANBgNVBAsTBldQIDUuNzEoMCYGA1UEAxQfU2VydmVy Q0EgPHNlY3VyZS5lLXRheG9ub215LmV1PjEoMCYGCSqGSIb3DQEJARYZc3VocmJp ZXJAaW5mLmZ1LWJlcmxpbi5kZTAeFw0wNzA4MTQxNDI2MDNaFw0xMjA4MTIxNDI2 MDNaMEkxCzAJBgNVBAYTAkVVMQ0wCwYDVQQKEwRFRElUMQ8wDQYDVQQLEwZXUCA1 LjcxGjAYBgNVBAMTEWlkcC5lLXRheG9ub215LmV1MIICIjANBgkqhkiG9w0BAQEF AAOCAg8AMIICCgKCAgEAyYGG3QDpZSc7/9JSzV1y4RL4+CtbhKDhaBu951xpNQnZ m1lMl9Xa7iJAtUdF0OrwgOVZTqrMQAW6ozan9kIxs+CH8vaGDVOwoakYh5Sa8jAG ZlhxxAF+ivkc1I9O9kBbYUs0rIkGRGgOnp8bSoekxqtUrcSRH+L5MWiF3BYnGqry 3Q5VsrGU7gI1aDPLbJPBV/5eVCurP51ETuS/hLc94PH6McAxl1hfrBkprL3SqtoE eIaobIlMFWItMwKLBN0S5hxOdB517gsGhzj8RtuVLEbJ1P3UnOcZ+t6qzZDKBlFD +cx8EG2LQHig9ZqEF7aXBFeIw16Hcpcd1/yzv4KInhZig8aHnUwDjAihYy6PomPf YACF6GQGCVns+yPeC8CAlNNjei+xItY8VjOGzRtbBP2i6nNQuhjbZ33IuXKvOUKi q/mNuppqgFV1M672vvGYJns2l7yx/XMKml0jo83ChpEp5aWfHJfJ66Mo5Vca+hnF dozklIP9rXD/37pvuJp3T13v8ZZnafjvJ206TVx7VkTS/dTP1vsHayKSLU0jVP88 NoYzNK1fwiAh4frU7xQIcbTCF7s084ZAGrLeWXdfYHa/LlQgH/XH6/hA+n1DqjQr i2+vrPZ46bAomYZwzuznjG7mM1PAZqGuPFAzfAuP2m++4GTf20mO+uIlKT/kUK8C AwEAAaOCAVgwggFUMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgbAMCsGCWCG SAGG+EIBDQQeFhxUaW55Q0EgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW BBQDgm8huZWg9FSa9PZTy8obfgeEHTCBoAYDVR0jBIGYMIGVgBRN9+1IWVSEJR/3 b1JY6166vOHcZ6F6pHgwdjELMAkGA1UEBhMCRVUxDTALBgNVBAoTBEVESVQxDzAN BgNVBAsTBldQIDUuNzEdMBsGA1UEAxMUc2VjdXJlLmUtdGF4b25vbXkuZXUxKDAm BgkqhkiG9w0BCQEWGXN1aHJiaWVyQGluZi5mdS1iZXJsaW4uZGWCAQEwJAYDVR0S BB0wG4EZc3VocmJpZXJAaW5mLmZ1LWJlcmxpbi5kZTAPBgNVHREECDAGhwSgLT8V MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAgEAPquo66iULZPmlz1o K9L4KX+cehtL1bbFKv9XqMV050tqurkRr9+mIOO1mFye6zZ9RNs40yw1n4+gEVnj x6y9JkGuwkhz9E+Wy+EU4NMVWuWkwnSTBKoDEPf6Copvu7+6bAlW+HUJAFj5Thr3 YNgOKnl9tnl6yKZL6htDuKN+aXKeMh8JdoPEy5YNy+b8nrC7xEAvRwnV1aq2ca9K Pq7H48fU/rPahdiYPeZqdLAbKTH0nmYU+fa0868UVjMmfoibfyObIX7xVyNyCiC5 Xcd8CbnDdIvWl3/3ZTmrHvJzsLPQQidLR7Ak9ujo7yXPu0WW3HlvyriFwwKUOVlL 81XNqlCfEWVs7b8gfOZmrLndUEqH6Y7uFcoVNCOCOr0D+Uq7FL3QJF7wKnwikpgw Lqn8tmFoMr0MTmLOYMfKy+u5Xvw6O5LYBS42sJjn1CfiQbrriIUL4JNgo3efsU0d M+ivcekSRCMFTGU60C3w+sD8HMn26uy/en4sTaDRsxXyPe7GxJsG42WGUK6oddRF XXg7cQZ3u3YwttvV8eelgFXP9hvyk0JxwGkxOlIQx5e7ibQTLwshRVFZ83pBCD8n hPDDISO8yvSJuBPJUrp6Y74ATl6VcalKCV3PsC9/ZAdLKNOrG9L8I1ut9MNE64sz 7BOrHuNQuTlOQhxvxa22Mwl4C0M= </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.e-taxonomy.eu:8443/shibboleth-idp/AA" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> <NameIDFormat xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> urn:mace:shibboleth:1.0:nameIdentifier </NameIDFormat> </AttributeAuthorityDescriptor> <Organization xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <OrganizationName xml:lang="en" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> EDIT Cybertaxonomy Identity Provider </OrganizationName> <OrganizationDisplayName xml:lang="en" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> EDIT Cybertaxonomy Identity Provider </OrganizationDisplayName> <OrganizationURL xml:lang="en" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> http://www.e-taxonomy.eu </OrganizationURL> </Organization> <ContactPerson contactType="technical" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <GivenName xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> Lutz </GivenName> <SurName xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> Suhrbier </SurName> <EmailAddress xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> suhrbier@inf.fu-berlin.de </EmailAddress> </ContactPerson> </EntityDescriptor> <EntityDescriptor entityID="https://sp.testshib.org/shibboleth/testshib/sp" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <KeyDescriptor use="signing" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> MIIGnzCCBIegAwIBAgIBBjANBgkqhkiG9w0BAQUFADCBgTELMAkGA1UEBhMCRVUx DTALBgNVBAoTBEVESVQxDzANBgNVBAsTBldQIDUuNzEoMCYGA1UEAxQfU2VydmVy Q0EgPHNlY3VyZS5lLXRheG9ub215LmV1PjEoMCYGCSqGSIb3DQEJARYZc3VocmJp ZXJAaW5mLmZ1LWJlcmxpbi5kZTAeFw0wNzA4MTQxNDI4MTNaFw0xMjA4MTIxNDI4 MTNaMEgxCzAJBgNVBAYTAkVVMQ0wCwYDVQQKEwRFRElUMQ8wDQYDVQQLEwZXUCA1 LjcxGTAXBgNVBAMTEHNwLmUtdGF4b25vbXkuZXUwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQC7YzmvMgq3jKgszVRtKbxQTR2qyUWiR6yu3nORPsXpZRsa kdiUJAhaYKqTs1MbsBiT/y7WOduODio1ZkCr64bBzbGYIQfyI5176Tvrh39hiw6H bGNOPSaoQv1b7efwLlVAn+dLnkBQvuAj8XDiiQco2mgIL/fsRhIKfqvpupzomshc 92L1lVeGmQYcE+dq4pEncAUAqIdIh8uOt6YrIO03hXUdRfyzD5h9oJWlA0SM4eQ4 hH5Uzmx3J7tLl6yQO9dKbZwFTKY53UzlqjV/nSX65TC+d3hjT6+OB5Jhx4N+z1Ng 4VTIeMZWESiinQR1akaxVReTrFG+rbRzJxeheFZrfxZ/LcNibQ5wOOd/R02UI/hG +k0uESPYO4czxsg6WjqdEw1GgQrJudrdnCKk9Xkx/UgT13LXTX1hIAGGmsViIxP/ DRaKOkC9zVF+ibQR8qJo1DAH0SVWSTNvFzZgKyTv7pmsNmuv2pfSqqe4M3bB448L qt1Vleh9oVKIjXQl5MJSNE7qLkUhVh4UPh+1wXz8GYdWUaJR4/pMmT0tnreQEbAg GwQWcyfAkHB51nRyeMH/tU5DLsAVMuUd6LDJts2CvR4hZnTdEOwySUNd8rzx4Z/R fYmaoh+WnIDP5HlB7z1WBDe9nDXwbqgVoCsqr6zF9RKsYpMXG9Yl4hberym1sQID AQABo4IBWDCCAVQwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBsAwKwYJYIZI AYb4QgENBB4WHFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYE FPesMK1gf4usprxr4adehYwGLzOLMIGgBgNVHSMEgZgwgZWAFE337UhZVIQlH/dv UljrXrq84dxnoXqkeDB2MQswCQYDVQQGEwJFVTENMAsGA1UEChMERURJVDEPMA0G A1UECxMGV1AgNS43MR0wGwYDVQQDExRzZWN1cmUuZS10YXhvbm9teS5ldTEoMCYG CSqGSIb3DQEJARYZc3VocmJpZXJAaW5mLmZ1LWJlcmxpbi5kZYIBATAkBgNVHRIE HTAbgRlzdWhyYmllckBpbmYuZnUtYmVybGluLmRlMA8GA1UdEQQIMAaHBKAtPxYw DgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQAMzH4YGYnbguRkot4C 0QDybm8Pp3QcNKtfO+8Nj4qjx9Z5uZuySJ11dy+qUnXHXTAj6tnuVkVFFxwqUggj uWDN7y2BeJTBpI1+z1WuONjJZTc4cNpnU+g2vYNLQ12+JBSH0WpGFp87UuSRQHfA mqSUj8l+pa6c7JvdmwPW11ZD4cpVHpzqiWKcJ7howMRqVVKRpClBZ9hGfiydj4wB I0VMvpZEJQ/hThdFN7+1eb0uy3R1Cvf5SKmhmXlGE0TnmO6I2f83jOTwWpiCX8Ow P3ykqbBiJRFsYTPLMYCMstp15NLXGr00MC1TOTUNvcVeA+OABZHl1lv3SJNp9uIA 1GnIAyLLLHYN+rcYSJID0utT8W8S96GVJSOBQL7RvEa4tvMO8WzweIZtKNdaeEFt ShOfSL0QyJpKKUA8pe5AajJi0jDIwSFeIO/si4xqGNmskzvAj+2PbSrRVKaBaRM7 DzV7bduFcOV+1GFrLn7aZ6+ZBrP0YkMqCh611lv7yhxGe0JTfWrgvnYZnvnE2vFs 8v4BKKoSwNcbQEoKnReefHUajK94JoyYCzKuj3x+tf7GaMthBMdcHTiW7IQIJx1n w72rUPU0gK5sUudVIBv6FPakpsnPQKB+h1/vrRsCBYMB51nemaIjT+sXANXii8o8 W4x9KrbmDvVehVpB4vPq6UR2mQ== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <NameIDFormat xmlns="urn:oasis:names:tc:SAML:2.0:metadata">urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://sp.testshib.org/Shibboleth.sso/SAML/POST" index="1" isDefault="true" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://sp.testshib.org/Shibboleth.sso/SAML/Artifact" index="2" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/> </SPSSODescriptor> <Organization xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <OrganizationName xml:lang="en" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> EDIT Cybertaxonomy Identity Provider </OrganizationName> <OrganizationDisplayName xml:lang="en" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> EDIT Cybertaxonomy Identity Provider </OrganizationDisplayName> <OrganizationURL xml:lang="en" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> http://www.e-taxonomy.eu </OrganizationURL> </Organization> <ContactPerson contactType="technical" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <GivenName xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> Lutz </GivenName> <SurName xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> Suhrbier </SurName> <EmailAddress xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> suhrbier@inf.fu-berlin.de </EmailAddress> </ContactPerson> </EntityDescriptor> </md:EntitiesDescriptor>
Basically, this file denotes the URI of the EDIT federation in the EntitiesDescriptor.
Then, several IdPs or SPs can be added to the federation within relating EntityDescriptors. These entity descriptors describe either IdPs (IDPSSODescriptor) or SPs (SPSSODescriptor). The most important entries are the
entityId (the providerID of the IdP or SP)
the certificate data (X509Certificate)
the URL's for the SSO service, the Attribute Authority, the Artifact Resolution service (IdP)
the URL's for the Assertion Consumer Services (SP)
Within the Organization and ContactPerson elements, you can provide some metadata about your site or site administrator.
We just used the default URL values. So, if you want to adapt this metadata for your own federation, it should be sufficient to adapt the DNS host name of our IdP (idp.e-taxonomy.eu) to that of your IdP, and to exchange the certificate data to the certificate data generated for your IdPs and SPs.
Updated by Andreas Müller about 2 years ago · 41 revisions