Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Extensible Connection Name Resolution (HRD) #937

Closed
GavinOsborn opened this issue Mar 21, 2017 · 3 comments · Fixed by #1052
Closed

Feature Request: Extensible Connection Name Resolution (HRD) #937

GavinOsborn opened this issue Mar 21, 2017 · 3 comments · Fixed by #1052
Assignees

Comments

@GavinOsborn
Copy link

GavinOsborn commented Mar 21, 2017

Scenario:

  • You already have an Auth0 solution that leverages the Lock widget to facilitate logon
  • You utilize the Home Realm Discovery feature to build a slick auth experience for users who have their own Enterprise IdP like Azure AD
  • For those users that don't bring their own IdP you want to be able to place them in separate database connections
    • Perhaps by e-mail domain or some other arbitrary rule

Problem
Unfortunately today the Lock Widget does not support a Home Realm Discovery experience for Database users. I can see why that might be.

Database connections support a number of different permutations that don't all lend themselves naturally to HRD and so you'd probably need to invest a reasonable amount of time and resources into making that work.

But many of your customers (myself included) would probably not have such open requirements.
We might be able to determine connection name from:

  • A naming convention (by e-mail domain for example)
  • An API request
  • etc

Proposal
From a layman's perspective HRD in Auth0 could be summarized as

"Given a username and some context resolve the name of the connection you'd like to authenticate against"

Could you build an extensibility point into the Lock widget that allows us to inject our own logic here?
Something similar to the below...

// This is hand written and probably contains all manner of syntax errors - be nice :P
var lock = new Auth0Lock(client, domain, options)
lock.show({
      icon: 'foo.png',
      callbackURL: '/callback',
      responseType: 'code',
      connectionResolver: function(username, context) {
          var domain = username.split("@")[1];
          var chosenConnection = context.connections.find(c => c.domains.indexOf(domain) >= 0);
          // or perhaps...
          var chosenConnection = context.connections.find(c => c.name == domain);
          // Promises to support alternative async scenarios
          return Promise.resolve(chosenConnection.name);
      }
    });

Is this an area you would be interested in exploring further?

@yutan-convoy
Copy link

yutan-convoy commented Jun 16, 2017

this is a brilliant idea, do you have a timeline of when this feature become available in release or beta test? thanks.

@luisrudge
Copy link
Contributor

luisrudge commented Jun 17, 2017

This is in our short term todo list. No ETA, but soon ™️

@GavinOsborn
Copy link
Author

🎉 👍

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants