- OpenAM (OpenSSO) based Identity Provider (IdP) Installation on Debian Lenny
- Installing OpenAM (OpenSSO)
- Uninstall OpenAM
- Configuring OpenAM as EDIT Identity Provider
- Installing and Configuring a Keystore to enable signing capabilities
- Creating a hosted Identity Provider instance
- Backing up the IdP Configuration (Metadata)
- Configure the Identity Provider
- Restoring the IdP Configuration (Metadata)
- Managing the user database
- Extending the Federation
- Add Service Providers
- Installing OpenDS as user store for OpenAM
- Setting up EDIT Federation
OpenAM (OpenSSO) based Identity Provider (IdP) Installation on Debian Lenny¶
The protocol logs the IdP installation for EDIT's Identity Provider on the host idp.e-taxonomy.eu. Please, adopt this hostname to your individual setup requirements.
In preparation of the OpenAM installation procedure, the server requires installating and configuring following software packages
Postfix (SMTP Server for mail relay)
Sun JDK 6 (Java)
Apache Tomcat 6
Apache Web Server 2.2
Before doing that, ensure your server knows your localhost instance by its external DNS name.
Defining localhost DNS-alias¶
Ensure to create an localhost alias to your host name, which is identical to the DNS name of the host. Otherwise, you may run into a lot of troubles when installing OpenAM later on, because your installation will probably fail.
To avoid this, just edit /etc/hosts according to your needs, i.e. you should add an alias to your host name(idp.e-taxonomy.eu here).
127.0.0.1 localhost idp.e-taxonomy.eu idp xxx.xxx.xxx.xxx idp.e-taxonomy.eu idp
Please follow the instructions Postfix Installation (Debian Lenny).
Installing Sun JDK 6 (Java)¶
Java 6 is required to run Apache Tomcat 6 as well as OpenAM and OpenDS.
Please follow the instructions Java Development Kit 6 Installation on Debian Lenny.
Installing Tomcat 6¶
Apache Tomcat 6 servlet container is currently used to run the OpenAM software.
Please follow the instructions Apache Tomcat 6 Installation on Debian Lenny. In particular, any communication with an Identity Provider should be protected. Therefore, don't forget to follow the instructions about SSL Configuration in order to enable SSL on your Tomcat instance.
Installing OpenAM (OpenSSO)¶
While the prerequisites have been the easy part, things will get more complicated now. As Oracle took over SUN, they recently decided to abandon Open Source releases of OpenSSO. Fortunately, OpenSSO has found a new home at ForgeRock, but is called OpenAM now.
Downloading, unpacking and deploying the OpenAM distribution¶
After downloading, unzip the distribution preferably to /opt/opensso.
wget http://www.forgerock.org/downloads/openam/snapshot9.5/openam_snapshot_951RC2.zip unzip openam_snapshot_951RC2.zip -d /opt
The OpenAM distribution includes several tools (admin, configurator, diagnostic, patch and session). They should be extracted into respective sundirectories within /opt/opensso/tools:
mkdir /opt/opensso/tools/admin && unzip -q -d /opt/opensso/tools/admin /opt/opensso/tools/ssoAdminTools.zip mkdir /opt/opensso/tools/configurator && unzip -q -d /opt/opensso/tools/configurator /opt/opensso/tools/ssoConfiguratorTools.zip mkdir /opt/opensso/tools/diagnostic && unzip -q -d /opt/opensso/tools/diagnostic /opt/opensso/tools/ssoDiagnosticTools.zip mkdir /opt/opensso/tools/patch && unzip -q -d /opt/opensso/tools/patch /opt/opensso/tools/ssoPatchTools.zip mkdir /opt/opensso/tools/session && unzip -q -d /opt/opensso/tools/session /opt/opensso/tools/ssoSessionTools.zip
Next, deploy the file /opt/opensso/deployable-war/opensso.war to tomcat's webapps directory. Ensure the file is accessible and executable by tomcat.
cp /opt/opensso/deployable-war/opensso.war /opt/tomcat6/webapps/
Finally, (re)starting tomcat should deploy the opensso.war file automatically
Now, OpenAM should be accessible below the /opensso URL-path (e.g. https://idp.e-taxonomy.eu/opensso/.
Next, you have to choose your preferred setup method. There is a graphical setup provided at https://idp.e-taxonomy.eu/opensso/ or the command line configurator tool can be used. The first is quite good to make first steps with OpenAM. The command line configurator has the advantage of being scriptable, so this is the method shown here.
Having unpacked the configurator tool to /opt/opensso/tools/configurator (refer to OpenAM installation), copy the sample configuration file to e.g. root/opensso/opensso.config and customise it.
mkdir /root/opensso cp /opt/opensso/tools/configurator/sampleconfiguration /root/opensso/opensso.config
This is an example of the current configuration from idpdemo.e-taxonomy.eu, which will also serve as template for the coming Identity Provider release installed on idpdemo.e-taxonomy.eu. It deploys OpenAM to the URL https://idpdemo.e-taxonomy.eu/opensso/ and stores configuration files to /etc/opensso.
As we will reuse the already existing user database built up with OpenSSO and we don't want to confront users with new URL's, we keep all names consistent with the former product name (opensso).
The following configuration sets up the embedded OpenDS Directory Server (LDAP) listening on port 389 as configuration data store.
As recommended, the user data store will be held distinct from the configuration data store. For that, we connect to a second OpenDS instance listening on port 50636, which we installed following the OpenDS installation already mentioned in the Prerequisites section. Of course, we will use the SSL protected communication port, even though, the user data store is currently running on the same host.
Also, we use the same DN as ROOT_SUFFIX for both data stores. (I could not figure out from the documentation, if they should be different or not, because any examples use the same DNs for both?)
Consider to define an encryption key within the parameter AM_ENC_KEY. Otherwise, OpenAM generates a new one each time OpenAM will be redeployed in the future, which results in adapting other configuration options (e.g. password files) each time.
Please refer to the original tools/configurator/sampleconfiguration file for more detailed description of the configuration options.
SERVER_URL=https://idpdemo.e-taxonomy.eu DEPLOYMENT_URI=/opensso BASE_DIR=/etc/opensso PLATFORM_LOCALE=en_US AM_ENC_KEY=*encryption key' ADMIN_PWD=*admin-secret* AMLDAPUSERPASSWD=*amldap-secret* COOKIE_DOMAIN=.e-taxonomy.eu DATA_STORE=embedded DIRECTORY_SSL=SIMPLE DIRECTORY_SERVER=idpdemo.e-taxonomy.eu DIRECTORY_PORT=389 DIRECTORY_ADMIN_PORT=4444 DIRECTORY_JMX_PORT=1689 ROOT_SUFFIX=dc=opensso,dc=e-taxonomy,dc=eu DS_DIRMGRDN=cn=Directory Manager DS_DIRMGRPASSWD=*datastore-dirmgr-secret* USERSTORE_TYPE=LDAPv3ForOpenDS USERSTORE_SSL=SSL USERSTORE_DOMAINNAME=e-taxonomy.eu USERSTORE_HOST=idpdemo.e-taxonomy.eu USERSTORE_PORT=50636 USERSTORE_SUFFIX=dc=opensso,dc=e-taxonomy,dc=eu USERSTORE_MGRDN=cn=Directory Manager USERSTORE_PASSWD=*userstore-dirmgr-secret*
Next, if not already done before, start the Tomcat6 container and deploy the opensso.war file.
Also, ensure the OpenDS user data store is up and running. In opposition to older versions, OpenAM automcatically configures OpenDS as user data store and creates necessary entries.
Finally, start the configurator tool with an adopted version of the formerly described configuration file.
java -jar /opt/opensso/tools/configurator/configurator.jar -f opensso/opensso.config
If the configuration was successful, output should finish like
Loading Schema /etc/opensso/opends_user_schema.ldif...Success. Loading Schema /etc/opensso/opends_userinit.ldif...Success. Loading Schema /etc/opensso/opends_user_index.ldif...Success. Loading Schema /etc/opensso/opends_plugin.ldif...Success. Creating Web Service Security Agents....Done Setting up registration files....Done Configuration complete!
You should be able to login on https://idpdemo.e-taxonomy.eu/opensso/ as user amAdmin with the password configured in option ADMIN_PWD of your opensso configuration file (e.g.opensso/opensso.config).
If configuration was unsuccessful, stop tomcat first. Then remove anything within /etc/opensso.
Mostly, you must also redeploy the opensso.war to Tomcat. That means,
remove the directory /opt/tomcat6/webapps/opensso completely!
restart tomcat, and wait some time. The starting process can be monitored Tomcat's log file /opt/tomcat6/logs/catalina.out.
After startup, start the configurator again.
/etc/init.d/tomcat6 stop rm -R /etc/opensso/* rm -R /opt/tomcat6/webapps/opensso /etc/init.d/tomcat6 start tail -f /opt/tomcat6/logs/catalina.out java -jar /opt/opensso/tools/configurator/configurator.jar -f opensso/opensso.config
Configuring OpenAM as EDIT Identity Provider¶
Deploying a new instance of an EDIT Identity Provider involves several steps, which will be explained within the following subsections.
Installing and Configuring a Keystore to enable signing capabilities¶
Since, we want the EDIT IdP to sign any assertions and messages generated, a keystore must be provided and configured for OpenAM. If not already done during the Tomcat6 installation, please follow the instructions for the PKCS#12 Keystore creation and generate a PKCS!#12 keystore from your PEM encoded certificates.
Unfortunately, OpenAM does not support the PKCS!#12 keystore format. Therefore, we have to convert the PKCS!#12 keystore into a JKS keystore first.
Next, copy the JKS keystore to the default ssl location for private keys (/etc/ssl/private), and create a symbolic link to it from within the OpenAM configuration directory (/etc/opensso/opensso).
cp idp.e-taxonomy.eu.jks /etc/ssl/private/ chown -R root:ssl-cert /etc/ssl/private/* chmod 640 /etc/ssl/private/* ln -s /etc/ssl/private/idp.e-taxonomy.eu.jks /etc/opensso/opensso
Everytime when having deployed a new instance of OpenAM, either a key encryption key must be provided during the OpenAM installation procedure or a new key encryption key will automatically be generated by OpenAM which will be used to en-/decrypt e.g. passwords. Anyway, when installing OpenAM for the first time, the next step is to generate these encrypted password files and store them as keypass or storepass files for the OpenAM keystore (idp.e-taxonomy.eu.jks) in the OpenAM configuration directory /etc/opensso/opensso. It is assumed, that the cleartext password is securely stored in the file idp.e-taxonomy.eu.secret.
/opt/opensso/tools/admin/opensso/bin/ampassword -e idp.e-taxonomy.eu.secret >> /etc/opensso/opensso/idp.e-taxonomy.eu.keypass /opt/opensso/tools/admin/opensso/bin/ampassword -e idp.e-taxonomy.eu.secret >> /etc/opensso/opensso/idp.e-taxonomy.eu.storepass
Next, we configure where OpenAM shall generate its keystore and where to store the encrypted password files. For that, adopt the following keystore.properties file to your needs. The following example simply denotes the locations of the keystore, the key/storepass files and the alias of the certificate within the keystore to use for the host idp.e-taxonomy.eu.
%BASE_DIR% corresponds to the option BASE_DIR and %SERVER_URI% to the option DEPLOYMENT_URI as defined in the installation configuration file (refer to Basic Setup).
Next, we use OpenAM's administration console ssoadm in order to load the keystore.properties into the OpenAM instance. Here, the option -u denotes amadmin as the default user id of the OpenAM administrator. The option -f determines the cleartext password file. The option -s determines that the default server instance is used (we have just one) and -D references the properties file to load.
/opt/opensso/tools/admin/opensso/bin/ssoadm update-server-cfg -u amadmin -f idp.e-taxonomy.eu.secret -s default -D keystore.properties
Finally, restart Tomcat and watch the log files for any error messages.
/etc/init.d/tomcat6 restart tail -f /opt/tomcat6/logs/catalina.out
Creating a hosted Identity Provider instance¶
There are two options to create an IdP instance with OpenAM, using the web interface or using the ssoadm console. AS the ladder requires to have preconfigured configuration files, we will describe the web interface solution first and come back to the console solution later.
Using the web interface comes along with checking the basic functionality of the OpenAM instance. So, direct your browser to the URL of your IdP instance as denoted in the basic configuration file during setup (e.g. https://idp.e-taxonomy.eu/opensso) and login with OpenAM's administrator user id (amadmin) and password (refer to Basic Setup configuration file).
Next, within the tab Common Tasks click on the link called Create Hosted Identity Provider.
Now, within the section metadata, click on the selection tab for the Signing Key and select the name of signing key you defined above within your server's JKS keystore. Then, create a new Circle of Trust (CoT) called EDIT. Finally, click on the Configure button to store the new Identity Provider.
Backing up the IdP Configuration (Metadata)¶
For backing up the current configuration, we will use the ssoadm console. ssoadm reads the password for the administrator amadmin from a file. So, let's create a file called e.g. idp.e-taxonomy.eu.secret
cat '<YOUR AMADMIN PWD>' >> idp.e-taxonomy.eu.secret
List registered entities¶
Next, we can check, if the IdP instance was created successfully. The following command gives a list of registred entities (Identity Providers and Service Providers), and should include the entity id of our IdP.
/opt/opensso/tools/admin/opensso/bin/ssoadm list-entities -u amadmin -f idp.e-taxonomy.eu.secret -e '/' List of entity-ids: https://idp.e-taxonomy.eu:443/opensso
Backup entity metadata¶
The following command stores the IdP's configuration in two parts, the metadata (metadata-idp.e-taxonomy.eu.xml) and the extended metadata (metadata-idp.e-taxonomy.eu-extended.xml). While the metadata is for public usage and can be used later for distribution to connecting Service Providers, the extended metadata includes some options, which define the behaviour and the attribute map the IdP delivers to registered Service Providers.
/opt/opensso/tools/admin/opensso/bin/ssoadm export-entity -u amadmin -f idp.e-taxonomy.eu.secret -e '/' -y https://idp.e-taxonomy.eu:443/opensso -m metadata-idp.e-taxonomy.eu.xml -x metadata-idp.e-taxnomy.eu-extended.xml
Configure the Identity Provider¶
Configuring the Identity Provider can also be done using the web console. But it is much easier and faster doing it with the ssoadm console.
For instance, don't touch the generated metadata-idp.e-taxonomy.eu.xml file. But the generated extended metadata (metadata-idp.e-taxnomy.eu-extended.xml) requires some adaptation. Here is a summary of any changes to be done.
First, check if the entityID and the values of the attributes saeIDPUrl, signingCertAlias and encryptionCertAlias corresponds to your IdP server instance.
<EntityConfig entityID="https://idp.e-taxonomy.eu:443/opensso" hosted="true" xmlns="urn:sun:fm:SAML:2.0:entityconfig"> <Attribute name="saeIDPUrl"> <Value>https://idp.e-taxonomy.eu:443/opensso/idpsaehandler/metaAlias/idp</Value> </Attribute> <Attribute name="signingCertAlias"> <Value>idp.e-taxonomy.eu</Value> </Attribute> <Attribute name="encryptionCertAlias"> <Value>idp.e-taxonomy.eu</Value> </Attribute>
Next, add the following lines to the attribute map element. This determines all attributes about an authenticated user which will be delivered to Service Providers when requested.
<Attribute name="attributeMap"> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:postalAddress=postalAddress</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:sn=sn</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:givenName=givenName</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:telephoneNumber=telephoneNumber</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:eduPersonPrincipalName=uid</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:eduPersonAffiliation=memberOf</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:cn=cn</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:mail=mail</Value> </Attribute>
Next, ensure the following security related attributes were set to true
<Attribute name="wantNameIDEncrypted"> <Value>true</Value> </Attribute> <Attribute name="idpSessionSyncEnabled"> <Value>true</Value> </Attribute> <Attribute name="wantMNIResponseSigned"> <Value>true</Value> </Attribute> <Attribute name="wantLogoutRequestSigned"> <Value>true</Value> </Attribute> <Attribute name="wantArtifactResolveSigned"> <Value>true</Value> </Attribute> <Attribute name="wantLogoutResponseSigned"> <Value>true</Value> </Attribute> <Attribute name="wantMNIRequestSigned"> <Value>true</Value> </Attribute>
The following attribute determines the name of the federation (EDIT of course).
<Attribute name="cotlist"> <Value>EDIT</Value> </Attribute>
Finally, these attributes determine the default lifetime of assertions issued.
<Attribute name="assertionEffectiveTime"> <Value>600</Value> </Attribute> <Attribute name="assertionNotBeforeTimeSkew"> <Value>600</Value> </Attribute>
The Shortcut Alternative¶
Alternatively, download the original extended metadata file (metadata-idp.e-taxonomy.eu-extended.xml) and adopt the four values explained first to the host name of your IdP server only.
wget https://dev.e-taxonomy.eu/trac/raw-attachment/wiki/OpenAMIdPInstallDebianLenny/metadata-idp.e-taxonomy.eu-extended.xml sed -i s\'idp.e-taxonomy.eu'\'<YOUR IDP HOST>'\g metadata-idp.e-taxonomy.eu-extended.xml
Now, the remaining task is to upgrade the metadata of the hosted Identity Provider entity.
Restoring the IdP Configuration (Metadata)¶
Having an entity's (usually Identity Provider or Service Provider) metadata and/or extended metadata prepared, the following steps must be run to update the metadata of an entity. Using the following commandline, you can register an entity by its metadata to your OpenAM instance. If you only want to update the extended metadata only, remove the '-m' flag and value from the command line.
/opt/opensso/tools/admin/opensso/bin/ssoadm import-entity -u amadmin -f idp.e-taxonomy.eu.secret -e '/' -m metadata-idp.e-taxonomy.eu.xml -x metadata-idp.e-taxonomy.eu-extended.xml -t 'EDIT'
If you already registered an entity, the ssoadm will probably return an error message. In that case, you must delete the existing entity first, before importing its metadata from scratch again. Be sure to have backed up the current metadata configuration files before deleting the entity !
/opt/opensso/tools/admin/opensso/bin/ssoadm delete-entity -u amadmin -f idp.e-taxonomy.eu.secret -e '/' -y https://idp.e-taxonomy.eu:443/opensso
Finally, the EDIT federation's Identity Provider should be up and running now. The current IdP metadata should be accessible by the URL https://idp.e-taxonomy.eu/opensso/saml2/jsp/exportmetadata.jsp?entityid=https://idp.e-taxonomy.eu:443/opensso
Managing the user database¶
Backing up the user database¶
Extending the Federation¶
Add Service Providers¶
The following is current work in progress and may be outdated !!!
As it is always recommended to seperate configuration data from user data, we are currently using the current OpenDS to hold the user database. This directory server is also recommended by OpenAM, because its the only Open Source directory server supporting all required features addressed by OpenAM. So, we finished our first experiences with OpenLDAP quite quickly.
Downloading, unpacking and deploying the OpenDS distribution¶
OpenDS":http://www.opends.org provides current and previous releases as "promoted builds":http://www.opends.org/promoted-builds. Let's start downloading and unpacking the "current release 2.2.0 to the directory /opt.
wget http://www.opends.org/promoted-builds/2.2.0/OpenDS-2.2.0.zip unzip opensso_express_20090901.zip -d /opt
OpenDS can then be found in the directory _/opt/OpenDS-2.2.0.
Next, it must be deployed running the following setup command.
/opt/OpenDS-2.2.0/setup --cli --no-prompt -Q -p 389 --adminConnectorPort 4444 -D "cn=directory manager" -j opends-userstore-manager.secret -a -b "dc=opensso,dc=e-taxonomy,dc=eu"
The parameters -p and --adminConnectorPort denote the ports where OpenDS are reachable for usage or administration purposes respectively. Parameters -D and -j define the administator account for OpenDS (Distinguished Name), and a password file. The distinguished name of the base tree must be added with the -a and -b parameter.
More detailed information about the command options can be optained by the following command.
Prepare OpenDS as OpenAM user store¶
Next, OpenDS must be prepared to be compatible with OpenAM. This includes the actions described in the following subsections.
There are few extra objectclasses/attributes are required to be added to the OpenDS to fully exploit the OpenSSO's functionality.
Next, apply the following command to add the schema to OpenDS.
/opt/OpenDS-2.2.0/bin/ldapmodify -h localhost -p 389 -D "cn=directory manager" -j opends-userstore-manager.secret -c -f am_remote_opends_schema.ldif
add OpenDS configuration data¶
Next, apply the following command to add the schema to OpenDS.
/opt/OpenDS-2.2.0/bin/ldapmodify -h localhost -p 389 -D "cn=directory manager" -j opends-userstore-manager.secret -c -a -f configure_opends_userstore.ldif
This will configure the following issues
Adding the basic configuration users¶
For profile read and write permissions are required. There will be two users created under the root suffix (openssouser and ldapuser).
Adding the privilege to enable password reset for the other users¶
There is a special privilege that needs to be assigned for an user to reset password of other users. We need to add the password-reset privilege to the openssouser.
Adding the Access Control Instructions(ACIs)¶
There are four ACIs are required to make the OpenDS work with OpenSSO as user store.
ACI to allow read and search permissions for the ldapuser
ACI to allow all permissions under the root suffix
Add ACI to allow persistent search connection to the datastore configuration DN
Add ACI to prevent self modification of certain OpenSSO user attributes
enable Referential Integrity Plugin¶
This plugin is necessary in order to make sure when the groups are removed from the directory all of its references in the users' entries are removed automatically. Otherwise, deleted groups will show up in the users' profile even after the group has been removed from the directory server.
The plugin must be enable by executing the following command.
/opt/OpenDS-2.2.0/bin/dsconfig -h localhost -D "cn=directory manager" -j opends-userstore-manager.secret -n set-plugin-prop --plugin-name "Referential Integrity" --set enabled:true
Enable pre-encoded passwords¶
Enabling pre-encoded password is only required, if you want to import user data from other user databases. Otherwise, e.g. hashed passwords cannot be added or modified to user accounts.
/opt/OpenDS-2.2.0/bin/ldapmodify -Z -X -h localhost -p 4444 -D "cn=directory manager" -j opends-userstore-manager.secret -c -a -f configure_pre_encoded_passwords.ldif
Add EDIT users and groups to the OpenDS user store¶
Presumed, there are user and group excerpts from another OpenSSO instance, than, these data may be added by simply updating the store by the following commands.
/opt/OpenDS-2.2.0/bin/ldapmodify -h localhost -p 389 -D "cn=directory manager" -j opends-userstore-manager.secret -c -a -f idp-opensso-people.ldif /opt/OpenDS-2.2.0/bin/ldapmodify -h localhost -p 389 -D "cn=directory manager" -j opends-userstore-manager.secret -c -a -f idp-opensso-groups.ldif
If not, the structure of these files should look like the following example for users
version: 1 dn: ou=people,dc=opensso,dc=e-taxonomy,dc=eu objectClass: organizationalUnit ou: People dn: uid=test,ou=people,dc=opensso,dc=e-taxonomy,dc=eu objectClass: inetorgperson objectClass: person objectClass: sunIdentityServerLibertyPPService objectClass: iplanet-am-user-service objectClass: sunFederationManagerDataStore objectClass: sunFMSAML2NameIdentifier objectClass: top objectClass: inetuser objectClass: organizationalPerson objectClass: iPlanetPreferences objectClass: iplanet-am-managed-person cn: test sn: test givenName: test inetUserStatus: Active iplanet-am-user-password-reset-force-reset: true iplanet-am-user-password-reset-question-answer: AQIChgWNghXpGtwz7lWofWgQk+8RFwDp MeGna3MXAz0Gfx4= mail: sdfg uid: test userPassword:: hashed-password Q==
and groups respectively
version: 1 dn: ou=groups,dc=opensso,dc=e-taxonomy,dc=eu objectClass: organizationalUnit ou: Groups dn: cn=Developer,ou=groups,dc=opensso,dc=e-taxonomy,dc=eu objectClass: groupofuniquenames objectClass: top cn: Developer uniqueMember: uid=test,ou=people,dc=opensso,dc=e-taxonomy,dc=eu uniqueMember: ...
Adding OpenDS user store¶
After the basic configuration, our OpenDS user store should be added to the configuration. Please, download the current configuration file datastore_opends_attrs.txt. Please, update that file by entering the password of the opends-admin (cn=Directory Manager) in line 7. Then, load the configuration file with the following command to OpenAM.
wget -O datastore_opends_attrs.txt https://dev.e-taxonomy.eu/trac/attachment/wiki/OpenAMIdPInstallDebianLenny/datastore_opends_attrs.txt?format=raw /opt/opensso/tools/admin/opensso/bin/ssoadm create-datastore -u amadmin -f idp.e-taxonomy.eu.secret -t LDAPv3 -m 'EDIT User Store' -D datastore_opends_attrs.txt
Login Page customisation¶
In order to adopt look and feel of the different OpenAM login and error dialogs, you will need to enter OpenAM's Tomcat deployment directory. Therein, two subdirectories are of particular interest. The image directory and config/auth/default. The former is dedicated to store images like project logos. The ladder contains JSP-code files which may be adopted to individual project requirements. Note, the JSP files contain some OpenAM specific variables (Jato) which you should be considered before modification.
There is a brief blog entry regarding [opensso customizing login page](http://blogs.sun.com/bouyges/entry/opesso_customizing_login_page. A more or less detailed documentation is available here) .
If you like doing the same for Password Reset pages, then modify the subdirectory password/ui.
Please, as an example retrieve the current EDIT logo and JSP files, and copy them into their intended directory.
Adopt the dialog headline with the header attribute. Set echoPassword to true for enabling browser password caching.
Any adoptions are in the html code. Take care on jato:xxx tags and system variables like @<%= ServiceURI %>@
Copy your modified JSP files to /opt/tomcat6/webapps/opensso/config/auth/default/. This directory denotes the default login layout. If you want language specific adoptions, then use the language specific subdirectories like /opt/tomcat6/webapps/opensso/config/auth/defaultde/_ for german.
# EDIT Logo in Anmeldedialogen setzen cp EDITBackground.jpg /opt/tomcat6/webapps/opensso/images/login-backimage.jpg cp EDITLogo45x45.png /opt/tomcat6/webapps/opensso/images/PrimaryProductName.png # JSP and Datastore files cp *.jsp /opt/tomcat6/webapps/opensso/config/auth/default/
Define individual Password Reset Questions¶
Regarding the password reset function, you may add or modify predefined questions within the file amPasswordReset.properties. Therefore, simply define a placeholder (or call it variable), assign the relating question as text and add it to the end of the file. Here, the placeholder current-project is related to the question What is your current project?.
current-project=What is your current project?
To configure the questions being selectable by users on password reste, you must login as administrator (amadmin) to your OpenAM instance and go to Configuration/Global/Password Reset. There, you can add secret questions based on the placeholder you defined before in amPasswordReset.properties. For different localisations, there are localised versions of amPasswordReset.properties in /opt/tomcat6/webapps/opensso/WEB-INF/classes.
How to configure individual password reset questions with ssoadm ?
Setting up EDIT Federation¶
The OpenAM term used to describe a federation is called Circle of Trust (COT). So, the first step is to create a circle of trust called 'EDIT'
/opt/opensso/tools/admin/opensso/bin/ssoadm create-cot -u amadmin -f idp.e-taxonomy.eu.secret -e '/' -t 'EDIT'
Currently, the EDIT federation consists of one Identity Provider (this instance) and serveral Service Providers. The federation can be easily reconstructed, when the respective metadata is available or backed up from a previous OpenAM instance.
OpenAM separates Metadata into two parts, metadata and extended-metadata. While the metadata describes the IdP or SP configuration to the external world (e.g. service access URLs), extended-metadata is used to describe internal functionalities like signing/verifying requests. Both types are defined within XML-files.
The following command loads both metadata and extended-metadata and add the that entity to the EDIT COT. Replace metadata.xml and extended-metadata.xml by the respective entity files.
/opt/opensso/tools/admin/opensso/bin/ssoadm import-entity -u amadmin -f idp.e-taxonomy.eu.secret -e '/' -m metadata.xml -x extended-metadata.xml -t 'EDIT'
Examples of current metadata files for the idp can be found in attachment:"metadata-idp.xml" and attachment:"metadata-idp-extended.xml".
It should be noted, that within the extended metadata, the attributes to be delivered to SPs can be defined in the XML-Attribute attributeMap.
<Attribute name="attributeMap"> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:sn=sn</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:postalAddress=postalAddress</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:givenName=givenName</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:telephoneNumber=telephoneNumber</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:eduPersonPrincipalName=uid</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:eduPersonAffiliation=memberOf</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:cn=cn</Value> <Value>urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:mail=mail</Value> </Attribute>
Another important issue, is to declare that sessions will be synchronised, i.e. whenever a user logs out of the federation, any other SPs will be notified.
<Attribute name="idpSessionSyncEnabled"> <Value>true</Value> </Attribute>
Also, any attributes named like wantXXXSigned should be set to true. Enter the proper COT within cotlist. Also, enter the proper values for the attributes signingCertAlias and encryptionCertAlias (idp.e-taxonomy.eu), as they are defined in your keystore configured above.
Generally, when adding EDIT SPs to the COT (federation), metadata could be gathered by entering the following URL path of the SP: https://yourSP/Shibboleth.sso/Metadata. This presumes that you are about adding Shibboleth SPs to the federation, which currently is exclusively the case. Then, you should be able to download and save the metadata of the SP to add. Make sure to remove any XML element starting with the tag md:extension, as they will currently not accepted by OpenAM.
Please, retrieve the example files metadata-SPExample-extended.xml.
You should adopt the entityID at the beginning of the file. As for the IdP-extended metadata, set any wantXXXSigned to true and adjust the cotlist attribute having the value EDIT.