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.
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 name, last name, username, email address, and persistent id. The first four should be self-evident, for the persistent id we want a value that doesn't change for the user. This can be an AD object guid, an employee id, or any other value that doesn't change for the user. 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.
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.
Once testing is successful contact support and we will update the login page (https://<clienturl>) to reflect SSO login.
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.
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.
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.
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.