Bridge | Planning Steps
Cirrus Bridge solutions sit between your organization’s commercial identity management (IdM) solution (Azure AD, Okta, OneLogin, Google GSuite, or others) and the applications users need to access. A bit of planning before getting started will go a long way to reducing initial confusion. Consider the following questions:
Is your identity management (IdM) solution supported by the Cirrus Bridge? Cirrus Identity currently supports the following IdM solutions, and will consider supporting any other identity providers that support a bilateral SAML V2 or CAS connection (Professional Services May Apply):
Azure Active Directory
Other authentication sources such as On-prem Active Directory, OneLogin, LDAP enabled directories, or RDMS based identity stores (Professional Services May Apply)
What are the Service Providers (SPs) that will be accessed using the Bridge?
What is the approximate number?
Do these SPs all have the same attribute requirements?
Do any of the SPs have unique requirements? For example, do any of them us SAML v1 style inline scopes or expect assertions from an IdP with a SAML cert/key that is unique.
What capabilities of your IdM solution do you want to extend with the Bridge?
Will this be a new registration or will the Bridge take the place of an existing federated IdP?
Will the Bridge also function as a CAS identity provider?
What should ‘cas:user’ be set to?
What other attributes should be released with the CAS ticket?
What are the CAS service URLs?
Do any of the CAS services use proxy mode?
Do any of the CAS services rely on a static IP address -- said another way, are there firewall or other network policies that need to be considered?
Next you will want to look at Cirrus Bridge | Getting Started.