New Cirrus Bridge customers frequently ask, “Why does a Cirrus Bridge need read-only API access?”. Cirrus actively works to minimize Cirrus access to customer systems as it only creates liability on our end to have excessive privileges, so we're motivated to avoid that however supported within the limitations of the APIs provided by Okta and Entra ID.
The sole permission needed by the Bridge is read access to applications, and the Bridge uses this permission to retrieve metadata URL, application ID, and application name for apps at the time your users are attempting to access them. By doing this lookup in real time over the API, we can avoid persisting any of your configuration information or even retrieving configuration information beyond what is needed to support traffic to your Bridge. Attributes and other user information are retrieved via SAML assertion, so there is no need for us to have API access to users or other object permissions.
Only Conditional Access Bridges need read-only API access. Conditional access allows customers to:
- Configure the Cirrus Bridge to support application-specific settings on-demand without coordinating with Cirrus Support.
- Leverage features like Entra ID Conditional Access on an application-by-application basis.
- Have granular control of attribute release, user/group assignment, and other configuration options within the Entra ID or the Okta administrative portals.
The standard approach with Entra ID and Okta is to add each application individually to configure SSO. This quickly becomes unmanageable as the Cirrus Bridge integrates Entra ID and Okta with thousands of applications in the InCommon/eduGAIN metadata. Additionally, customers usually do not wish to implement the same attribute release and security requirements across all applications.
Unlike traditional applications that are integrated with Entra ID or Okta tenants in a “bilateral” trust using a SAML assertion, the Cirrus Bridge allows the integration of multilateral trust while still configuring specific attributes and security settings for single or groups of applications. The approach that supports this pattern is to add multiple enterprise applications - each representing a separate access configuration for a grouping of Service Providers to be integrated using the Cirrus Bridge.
Customers are not required to enable read-only API access to use the Cirrus Bridge, but it is required to utilize the conditional access features. Conditional access is what allows customers to have more control over what gets sent to the Cirrus Bridge and ultimately to downstream service providers. Please reach out to us if you have any additional questions.