Project

General

Profile

Actions

OpenAM (OpenSSO) based Identity Provider (IdP) Installation on Debian Lenny


This document will briefly describe the installation of the EDIT CSSO Identity Provider (IdP) based on the OpenAM software on a 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.

Prerequisites

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)

  • OpenDS

  • 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

Installing local mail relay with Postfix

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 OpenDS

OpenDS is a fully LDAPv3 compatible directory server, which is particularly recommended to be used as user store with OpenAM. Please follow the instructions OpenDS 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

The recent releases of OpenAM and OpenSSO are now located at ForgeRock. Currently, the most recent release is OpenAM Snapshot 9.5.1 RC2

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

/etc/init.d/tomcat6 (re)start

Now, OpenAM should be accessible below the /opensso URL-path (e.g. https://idp.e-taxonomy.eu/opensso/.

Basic Setup

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.

Note::

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).

Uninstall OpenAM

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.

com.sun.identity.saml.xmlsig.keystore=%BASE_DIR%/%SERVER_URI%/idp.e-taxonomy.eu.jks

com.sun.identity.saml.xmlsig.storepass=%BASE_DIR%/%SERVER_URI%/idp.e-taxonomy.eu.storepass

com.sun.identity.saml.xmlsig.keypass=%BASE_DIR%/%SERVER_URI%/idp.e-taxonomy.eu.keypass

com.sun.identity.saml.xmlsig.certalias=%BASE_DIR%/%SERVER_URI%/idp.e-taxonomy.eu

Note::

%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).

[!OpenAM-Loginpng|align=center!]

Next, within the tab Common Tasks click on the link called Create Hosted Identity Provider.

[!OpenAM-Select|CreateHostedIdentityProvider.png!]

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.

[!OpenAM-CreateSAMLv2IdentityProviderpng|align=center!]

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

Adding users

Backing up the user database

Extending the Federation

Add Service Providers


The following is current work in progress and may be outdated !!!

Installing OpenDS as user store for OpenAM

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.

There is a quite acceptable description available on Using OpenDS as user store for OpenSSO Anyway, the following section describe the installation steps for the EDIT IdP User Store.

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.

/opt/OpenDS-2.2.0/setup --help

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.

add OpenSSO schema

There are few extra objectclasses/attributes are required to be added to the OpenDS to fully exploit the OpenSSO's functionality.

Download the required OpenSSO schema attachment:am_remote_opends_schema.ldif"("original location.)

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

Download the required OpenSSO schema attachment:am_remote_opends_schema.ldif"("original location.)

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 EDITBackground.jpg and EDITLogo45x45.png image files to /opt/tomcat6/webapps/opensso/images/ and rename them as login-backimage.jpg and !PrimaryProductName.png respectively.

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/default_de/ 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.

TODO::

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.

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