Disabling a connection in an Application doesn't stop a user logging in

Get Help
,
1

We have multiple SAML enterprise connections (Conn_1, Conn_2, Conn_3, etc) with Home Realm Discovery enabled.
We have multiple applications (App_1, App_2, etc).

We have one application (App_1) with an enabled connection to one of the SAML enterprise connections (Conn_1) but none of the others (Conn_2 etc).

When we try to log into that application (App_1) with an email address that is referenced by Home Realm Discovery to another connection (Conn_2), we are finding that it redirects us to that connections Identity Provider for login.

I expected that as the connection was disabled, Home Realm Discovery would not be triggered for the connection.

Any ideas what we could be doing wrong?

1 Like
3

Hi @chris.butler,

Welcome to the Auth0 Community!

The behavior you’re observing is expected because Home Realm Discovery (HRD) operates at the tenant level, not the application level. It identifies the user’s enterprise connection based on their email domain before checking if that connection is enabled for the specific application they are trying to access.

The most direct and modern way to solve this is to create a custom Action that runs after HRD but before the final login is complete. This Action will verify that the connection selected by HRD is actually enabled for the application in question.

Here’s how you can set it up:

  1. In your Auth0 Dashboard, navigate to Actions > Library.

  2. Click Build Custom and create a new Action with the following settings:

  • Name: Enforce Application Connections
  • Trigger: Login / Post Login
  • Runtime: Node 18 (or your preferred runtime)
  1. In the code editor, paste the following script. This script checks if the connection the user is logging in with is included in the list of connections enabled for the current application.
/**
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login transaction.
*/
exports.onExecutePostLogin = async (event, api) => {
  // Find the connection the user is authenticating with.
  // In federated logins, the strategy is the connection name (e.g., "samlp").
  // The `event.connection.name` holds the unique name of the connection.
  const connectionUsed = event.connection.name;

  // Get the list of connections that are explicitly enabled for the current application.
  // This is an array of connection names.
  const enabledConnections = event.client.enabled_connections || [];

  // Check if the connection being used is in the application's list of enabled connections.
  if (!enabledConnections.includes(connectionUsed)) {
    // If not, deny access and provide a clear error message.
    api.access.deny(
      'access_denied',
      `The '${connectionUsed}' connection is not enabled for this application.`
    );
  }
};

  1. Click Deploy.

  2. Finally, add this Action to the Login flow. Go to Actions > Flows > Login.

  3. Drag your new Enforce Application Connections Action from the right-hand panel and drop it into the flow.

Now, when a user tries to log in, this Action will run and prevent them from using a connection that isn’t explicitly enabled for the application they are accessing, stopping the process before a session is created.

If you have any further questions, please don’t hesitate to reach out.

Have a good one,
Vlad

4

Hi @vlad.murarasu,

Thanks for the response. Its great to have clarify on what is expected.

It makes me question the value of enabling and disabling connections under and application? What is the purpose of this if HRD is going to be triggered regardless?

5

Hi @chris.butler,

The primary purpose of the Enabled Connections setting on an application is to control the UI of the Universal Login page by determining which login buttons are displayed to the user. HRD operates at an earlier stage of the login flow, which is why its behavior can seem counterintuitive.

Its primary role is to configure the UI for users who aren’t automatically routed by HRD. The Action I’ve suggested simply enforces that same logic earlier in the process for a more robust and intuitive flow.

Have a good one,
Vlad

6

Thanks for the reply and understanding. Its massively appreciated.

Is it possible to make a suggestion/feature request that HRD becomes an application level concern instead of the tenant level concern? It feels like it could be a good opportunity to the use of connections within applications for federated connections

7

Yes, you can submit a Product Feedback topic and request that this feature be implemented.

Everyone else who thinks they can leverage this feature can vote on your Product Feedback.

Have a good one,
Vlad

8

Hi,

Thanks for the link.

I’ve just begun coding this and can’t see enabled_connections being available in the client object within the docs? Is this an unsupported property?

I’ve navigated to: /docs/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-event-object

9

Hi @chris.butler,

Apologies for my mistake. The enabled connections are not available inside the event.client object but need to be accessed using the Management API.

Here is the documentation for the Get enabled connections for a client endpoint:

You can leverage the ManagementClient for use within the Action:

If you have any further questions, please don’t hesitate to reach out.

Have a good one,
Vlad