The steps listed here are the minimum required to get a functional instance of COmanage Registry up and running, so you can see how it works with the Shibboleth SP. If you're interested in deploying COmanage Registry in production, please refer to the official documentation.
Download and Install COmanage Registry
Download a stable release of COmanage Registry (note: version 2.0 is now available, but not yet tested with these instructions):
Extract the tar file:
You should now have a directory
/opt/comanage-registry-1.0.6, which contains all of the files in the distribution. Next, create a couple of symbolic links to facilitate configuration and make the application visible to the web server:
COmanage Registry needs a temporary directory to store cached files, logs, etc. The directory must be writable by the web server. Set a temporary directory up as follows:
Install Prerequisite Packages
COmanage Registry is written in PHP, and requires several PHP modules, as well as a local database. For this installation, we'll use MariaDB, which is a drop-in replacement for MySQL that ships with CentOS 7.
Next, start the database server and run the
The script will prompt you to set a password for the 'root' database user. Choose a secure password, and remember it for later. You can accept the default option at each of the subsequent prompts.
Configure the Web Server
/etc/httpd/conf/httpd.conf, and add the following sections.
This section enables Shibboleth authentication:
Finally, add a redirect to handle logout:
Don't forget to substitute your chosen hostname for
my.special.name in the above example.
Configure the Database
First, you'll need to create a database for the registry tables. Don't forget this step, or you will get an unhelpful error message when you run the script to populate the schema.
Next, create a local copy of the default database configuration file:
Then, edit the resulting
database.php file, and make the following changes:
- Set 'login' to 'root' (Note: for a production installation, you'll want to create a separate, non-privileged user.)
- Set 'password' to the top-secret password you chose when you ran the
- Set 'database' to
Finally, run the script to create the database schema:
You should see the message "Database schema update successful", possibly intermingled with other output.
Set Up an Administrative User
Almost finished! Now, we just need to "bootstrap" the registry by adding an administrative user. As you did earlier, you'll be logging in via the InCommon Training IdP, which has three pre-existing users:
faculty1. Choose any of these (it doesn't matter which you use).
COmanage checks the identity of the authenticated user by looking at the
REMOTE_USER environment variable. For this demonstration, we'll want to make sure that
REMOTE_USER is populated with the user's
eduPersonPrincipalName (ePPN). The ePPN is just the user's login name with a "scope" appended, e.g. "user@scope". The training IdP uses
example.org as its scope, so typical ePPNs will look like
You may recall that the SP can be configured to populate
REMOTE_USER with any attribute it receives from the IdP. ePPN is the default, but to be safe, you should verify this. It's configured in
/etc/shibboleth/shibboleth2.xml, in the
<ApplicationDefaults> element. Look for the
REMOTE_USER attribute, and ensure that "eppn" is the first item in the space-delimited list:
When you're ready, run the registry configuration script. You can enter any values for given name and family name, but make sure the login username is of the form email@example.com. It needs to match the ePPN that the IdP sends in the assertion.
Test the Installation
You're now ready to test the installation:
- Restart Apache (
systemctl restart httpd)
- Browse to