EAA Bridging overview

EAA allows you to use federated SSO for your SAML applications using a SAML IDP providing more flexibility for users to access the enterprise applications.

EAA acts as a bridge when an end user belonging to a third-party SAML IdP accesses a SaaS application, Access Application, or a HTTP (web) Application.

The steps involved in allowing the user to access the application are as follows:

1. User clicks on the application (for example, JIRA) he wishes to access.
2. The application requests the user to validate himself with the third party IdP (for example, Okta). This request lands on EAA.
3. EAA cannot authenticate the user since the user belongs to Okta IdP. EAA behaves in bridge mode and acts as a proxy. It constructs a SAML request and sends it to Okta IdP.
4. Okta IdP authenticates the user and sends back a SAML response to EAA.
5. EAA sends the SAML response to the JIRA application.
6. The application knows that the user is validated and allows him to access the JIRA application.

EAA bridging capability works between third party SAML IDP and SAML application. For more details, see SAML to SAML bridging. It is only supported for SP initiated flow and not for IdP initiated flow.

EAA currently does not support SAML to WS-Federation bridging, OIDC to WS-Federation bridging, SAML to OIDC bridging, OIDC to OIDC or SAML to OIDC bridging mechanisms.