HelloID

In some cases, an SP-initiated HelloID SAML application can enter an infinite redirect loop. For example, this may occur when an app points to www.acme.com/saml, which then sends an SP-initiated authentication request back to the HelloID application URL, which then contacts www.acme.com/saml, ad infinitum.

You can solve this as follows:

In this way, the hidden SAML app is indirectly triggered to send the necessary information to www.acme.com/saml. Once the authentication request has finished, the user is redirected to www.acme.com by the application shortcut's Default Login URL. An endless loop is avoided.

Some SAML and OIDC applications have both test and production environments. Typically they share the same SSO settings, and whenever the production environment's SSO settings are updated on the SP side, they are automatically copied to (i.e., overwritten in) the test environment. In this case, having separate HelloID applications for the test and production environments will require you to update both applications any time the SSO settings change on the SP side.

You can avoid this duplication of effort by adding the production environment as a normal HelloID application, but adding the corresponding test environment as a shortcut. In this way, you won't have to separately update two applications.

Some applications have several sub-applications, or "endpoints". Instead of sending users directly to the main application, you can hide it and instead create separate shortcuts for each endpoint that goes to an SP-initiated URL. In this way, each shortcut will be (indirectly) routed through the hidden application, which stores a single set of application options and a single mapping set.