In ForgeRock ID Cloud (FIDC), using SAML federation with external Identity Providers or Service Providers is quite straightforward. Simple steps to follow are available here - https://backstage.forgerock.com/docs/idcloud/latest/applications-saml2-jsp.html
The following is a special case.
A customer has several applications which are accessible only to user with a valid OIDC id_token issued by FIDC. This customer in turn is providing these applications as service to its own customers (b2b). Some of the customer's customer users can register for an account and credentials in FIDC and use those credentials to authenticate and get an OIDC id_token to authenticate themselves to applications. But, larger organizations tend to have their own IAM systems and prefer to setup federation between those and the applications that their users need to access. SAML is still quite popular in these large organizations. For users of these organizations, FIDC essentially becomes a federation broker. When these users access customer's applications, they are redirected to FIDC, which in turn redirects them to the user's IAM (IdP). They authenticate with their IAM system and federate into FIDC with a SAML assertion, and in turn FIDC (after validating the assertion) will dole out an id_token to these users.
The SAML side of the above flow is an SP initiated federation scenario, where the users access SP (in this case FIDC) without an active authentication token/session and are sent by SP to the IdP for authentication. Normally, we will configure this flow in FIDC by:
- Configuring a circle of trust, a hosted SP and a remote IdP
- Configuring an authentication tree/journey with SAML node. The SAML node is configured with the entity id of the remote IdP.
A separate instance of SAML node is needed for each such remote IdP. When dealing with a small and relatively unchanging number (5-10) of remote IdPs like this, the above is not a problem. But when dealing with 10s or even 100s of remote IdPs, and maybe more being added as new customers sign up, the above can quickly become a maintenance and administration problem.
In on-prem deployments, this is easily solved by creating a custom SAML node, where remote IdPs entity Id value is dynamic (based on some request parameter or user attribute). In FIDC, this is not an option.
This article provides an alternate way of achieving this. Here is a flow depicting this.