New Cirrus Bridge customers frequently ask, “Why does a Cirrus Bridge need read-only API access?” The following blog post and video address this question.
The Cirrus Bridge is designed to:
• Enable customers to leverage features like Entra ID Conditional Access on an application-by-application basis
• Give customers granular control of attribute release, user/group assignment, and other configuration options within the Entra ID or the Okta administrative portals.
Our customers can configure the Cirrus Bridge to support application-specific settings on-demand without coordinating with Cirrus Support.
The standard approach with Entra ID and Okta is to add enterprise applications individually to configure SSO. The Cirrus Bridge integrates Entra ID and Okta with thousands of applications in the InCommon/eduGAIN metadata. However, 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.
To provide this capability, the Cirrus Bridge uses the read-only API access native to Entra ID and Okta to dynamically read the configuration of Cirrus Bridge enterprise applications configured in Entra ID or Okta. For more information about how this works, watch the video “Why does the Cirrus Bridge need API read-only access to my Entra ID or Okta tenant?” below.