Lock: Allow connectionResolver to resolve to AD and other enterprise connections

[nicosabena]

Lock v9 provided the options and context parameters in the events that allowed some interesting magic to happen. In particular, by analyzing the context and changing the options, you could decide that the target connection for the authentication was an AD/LDAP connection. One interesting use, for instance, was using the default DB connection if an email was entered in the first field, or switch to a specific AD connection if a username was used instead (no @).

While Lock 10/11 don't allow changing options dynamically, it seems that this use case would be better served by the connectionResolver, except that it currently only supports database connection. Ideally, connectionResolver should also support using AD/LDAP connections and other types of enterprise connections that support "active" authentication (like ADFS and Azure AD depending on configuration).

To support this use case, there should be some way of configuring the username/email text field to allow it to freely type either usernames or emails (this might also be desirable even when switching between different database connections, as some might support username while others don't).

[nicosabena]

Related https://github.com/auth0/lock/issues/1194, because currently the resolver apparently validates that the returned connection is in the list of available connections for the client (up to 50 returned).

[cocojoe]

@nicosabena this has been added to an internal discussion regarding the improvement of the connectionResolver in general. Thanks for raising.

[kjk129]

In our case, we have significant number of customers used to using the AD/LDAP connections with Lock 9 where they can just enter just their User Name ( minus the @domain.com suffix ). In Lock 11, it would be nice to be able to preserve this behavior to avoid the need for users to enter the fully qualified [email protected]. We typically have both an AD/LDAP & Azure AD connection bound to a each Client, so there remains a need for Lock to resolve the correct connection at run-time based on what the user types. In other words, we can't just initialize Lock with a specific Connection.

[luisrudge]

@kjk129 lock already supports that out of the box.

[kjk129]

Luis – Could you explain how to achieve this behavior?

[luisrudge]

Sorry, I should've be more clear: If you have less than 50 connections in total, it handles OOTB. Otherwise, we fall into this issue that we're trying to solve, which is figure it out at runtime which connection to use

[kjk129]

Per Client, we only have 2 Connections configured total. One AD/LDAP and one AzureAD.
I'm not sure what OOTB means ?

[luisrudge]

out of the box. If you have only two, lock will initiate the HRD (home realm discovery) automatically when the username domain matches your connection domain.

[luisrudge]

https://auth0.com/docs/libraries/lock/v11/selecting-the-connection-for-multiple-logins

[kjk129]

Yes, this is indeed how Lock 11 is behaving. It is just different than Lock 9 behavior where in that case the user could simply enter the UserName only and a Password and then proceed with the authentication in one click. Somehow the Lock 9 widget determined to use the AD/LDAP connection (even without the domain entered) and to authenticate using the legacy /ro endpoint.

[luisrudge]

ah, sorry. I misread your comment. You're saying that v9 did HRD without the user typing the domain name, right? Did you add any configuration to make that happen? I have no familiarity with v9 at all, so I'm not sure how would that be possible, considering you have two connections to chose from

[kjk129]

Correct. Below was the specific configuration we used in Lock 9. With UsernameStyle set to 'username', you wouldn't think that Azure AD or SAML connections would necessarily work with [email protected] entered, but the Lock 9 would still resolve the correct connection for those user names as well.

                popup: true,
                sso: false,
                rememberLastLogin: false,
                disableSignupAction: true,
                disableResetAction: true,
                usernameStyle: 'username',
                socialBigButtons: false,
                focusInput: true,
                icon: '/images/Logo.jpg',
                defaultADUsernameFromEmailPrefix: true,

[sdanbury]

Also interested in the logic @nicosabena was talking about with being able to pick an enterprise connection based on what is entered into the username box.

I would like to do some enterprise connection selection logic based on username suffix like so:

connectionResolver: function (username, context, cb) {
  var suffix = username.endsWith('_blahblah');
  if (suffix) {
    cb({ type: 'enterprise', name: 'ldap-connection' });
  } else {
    // Use the default approach to figure it out the connection
    cb(null);
  }
}

[luisrudge]

Hi! I'm sorry about the copy/paste message, but I'm cleaning up some stale issues. 🗑
It's been a while since this issue was opened. Are you still having this issue with the latest version? If so, please reopen it with some repro steps so we can help!