Configuring Single Sign On (SAML/SSO) with OneAegis

Contracting & Enablement

A support team member will need to do the initial enablement in the administrative section of OneAegis. This must be completed before you can retrieve the metadata in the next step. Make sure your agreement includes the Single Sign On add-on. This is an optional component and must be part of your contract to enable and use. 

Setup

Once enabled you can retrieve our metadata at https://<clienturl>/saml2/metadata, if you need a metadata file. But often all need is our entity id and ACS endpoint. The entity id will be the same as your login url (https://<clienturl>), and the ACS endpoint is https://<clienturl>/saml2/post. 

We need 5 data elements passed in the SAML response:

• First (given) name
• Last (family) name
• username
• email address
• persistent id

The first four should be self-evident, for the persistent id we want a value that does not change for the user. This can be an AD object guid, an employee id, or any other value that does not change. Depending on your institutional policies the username is also a possible value, assuming you don't change usernames. If you don't have a non-changing value we can use username but be aware that you will need to synchronize username changes in OneAegis manually. 

We will need to know the attribute names you're using for these data values, and we will also need your metadata, or at least your entity id, login endpoint, and signing certificate. If you're using Entra (AzureAD) we know the standard attribute names, just let the team know you're using Entra. 

Testing

Once setup you can test a SAML login by visiting https://<clienturl>/saml2/initiate. This link should direct you to your IdP, and after login, back to OneAegis. You should be logged in at this point. Whether you're forced to login at the IdP depends on your IdP configuration and whether you want us to request a force-authentication in our SAML request. It's very possible though that you'll get an initial failure depending on attribute mapping in the SAML response, that's ok, just let us know the error id and we can check (and fix) the mapping on our side.

Go Live

Once testing is successful contact support and we will update the login page (https://<clienturl>) to reflect SSO login. 

Advanced Features

We can map additional attributes to UDFs and Departments. We can also lookup users using non-standard attributes. Discuss these requirements with the support team. 

Applicability

This article discusses the current SSO integration with SSO and OneAegis. This is correct process to use for all new integrations, and existing migrations should move to this process as soon as practical. If you have a legacy integration (SP of https://shibboleth.irbmanager.com) please contact support for configuration changes and consider upgrading as soon as possible. 

Replacing our old (Shibboleth) SSO Configuration

For those clients with existing (Shibboleth-based) SSO implementations you'll note that we have a new entity id. The old entity id was https://shibboleth.irbmanager.com/. Please do not disable or change this old entity, users will continue to use this while we setup and test the new implementation. We also want (need) to make sure that the persistent identifier used to map users does not change. In many cases this was the ObjectGuid from within Active Directory on your side, but more importantly please check what you're currently sending as the persistent id in the old (shibboleth) configuration and replicate that in the new configuration. Note, we can make changes here, but it's more work; if we can keep the identifier the same it is much better. Also, note if you're sending additional attributes as part of the old configuration, you'll want to replicate those to the new configuration.