Table of Contents Overview
Table of Contents
Overview
This document outlines the identity provider specific steps required to configure an Okta Application for the Cirrus Enterprise Bridge. For the full process, visit Getting Started with Cirrus Bridge. You will follow each of these steps for each new application that you add.
To complete these steps, you will need the information for at least the default profile that you created from the Authentication Profiles for Cirrus Bridge page.
Additionally, each unique authentication profile requires its own Okta application. An authentication profile includes the NameID format and value, set of attributes, and set of signing and encryption settings. A typical implementation will include the default profile(s) for each protocol, and then one or more additional profiles if required by the service providers. Your Cirrus Implementation Lead will work with you to develop these additional profiles and provide support for configuration. While the default application can support multiple Entity IDs, Okta only allows a single Entity ID or Entity category per application for additional applications.
Add Application
As an Okta admin, log into your Okta instance and click the “Applications” left menu item, and then click “Create app integration”.
Select SAML 2.0 as the Sign-in method.
Name the application. For the “Default” Cirrus Bridge application, we recommend “Cirrus Bridge Default” and check the box to ‘Do not display application’.
Step 1 - Configure SAML Parameters
Enter the Single sign on URL and Audience URI (SP Entity ID) provided to you by your Implementation Lead. Pick the Name ID format of transient. Most InCommon apps want a Transient Name ID format, which should be the setting for your default bridge. Cirrus does not use the application username value for Transient Name IDs. You may specify another Name ID format or value for individual apps.
Step 2 - Signing and Encryption Settings
Click on ‘Show Advanced Settings’ to update these settings. Okta signs both the SAML response and assertion. Some applications only want one or the other signed. Our recommendation for the default application is to only sign the response. This configuration will match Shibboleth’s default behavior.
Encryption is optional. Shibboleth encrypts assertions by default. To enable encrypted assertions with the Cirrus Bridge, you set encrypted assertions (and upload the bridge’s public certificate) in the Okta configuration for the app.
Step 3 - Add Attributes
Next, the attributes will be configured. Please refer to the list you created from the Authentication Profiles for Cirrus Bridge page to configure these attributes.
When you are done, the Attribute list will look something like the following. You may have additional attributes that you have added to the profile so it would differ in that way.
Step 4 - Configure MFA
Okta can signal to the Cirrus Bridge that MFA was used if you release the “session.amr” attribute to Cirrus. To do this, in Attribute Statements add the following attribute:
Name: session.amr
Format:: Unspecified
Value: session.amr
Step 5 - Save the Application
Click Next. Optionally fill out the Okta support questions and then click Finish.
Assign App to Okta Group
The configured application in Okta needs to be added to the group created during the pre-provisioning process before it can be recognized by the Cirrus Bridge.
Testing
Now that your Enterprise Bridge is configured within Okta, please return to the Testing section of the Getting Started documentation to test your Bridge.
Blog comments