Possibility to select connector in client request

[pbochynski]

Right now if there is more than one connector configured user has to select one before he is redirected to the authentication page. It should be possible to skip that step if a client has preferred connector, e.g. google.

The change is rather simple: #1083

[ericchiang]

Thanks for opening this!

Copying my response from #1026 (comment)

We've consider this in the past, but this has a lot of implications and questions around guarantees. Should it be a scope? Client configuration? Should a user be able to change this value? Do we have to guarantee that the user can't use other connectors? Can an end user see the other connectors? Would a client be surprised if they used this feature and a user logged in through a different connector?

The change being simple is something we consider but isn't an argument for why the feature is useful or what it needs to do.

I'm trying to get a sense of why this feature would be used. What's your exact use case here? We've heard crazy things like clients needing to only be able to see certain connectors. But this doesn't sound like that.

[pbochynski]

My use case:
I am providing application for customers deployed on kubernetes. I have two apps: for operator (me) and for customers. Both applications use kube-apiserver API (of course with different roles). I want to be authenticated by my enterprise SSO (SAML2). My customers have own SAML provider. They should not think about which connector to use.

Other reasons:

• having social login buttons directly in the client application with nice icons (like Auth0)
• as you said other people requested it before that means they also had reason ;-)

[kiich]

My use case is for 2 different LDAP connectors where handful of users only exist in one LDAP and rest in another LDAP. If I can have a way to specify which (LDAP) connector to use in the client request, or a way to programatically choose which from the screen with selection, that would be handy for me.

[pborzenkov]

+1 for this.
The main reason for me is to be able to have social login button nicely integrated into the application.

[sdrozdkov]

I did PR some time ago:
sdrozdkov@dfbabdd

This functional added with param &connector to auth requests.
If need I can do needed changes for merge this.

[jollinshead]

Our team has a similar requirement to @kiich 's.

@sdrozdkov Could you make a pull request?

[dbkegley]

Any updates on this issue? We would like to use this feature as well, our use case is similar to @pbochynski's. We have multiple customers, who may or may not have an internal IDP. If they have one then we would like to configure a dex connector so they can use their existing IDP to sign in to our application. If they don't then we would allow them to use our IDP. Our only requirement is that the user should not have to choose the desired connector, we should have the ability to choose it programmatically from our application. A nice-to-have would be if each client had a default connector configuration so that the client_id could determine which connector was used

[capripot]

We have the same exact scenario as @dbkegley. Maybe we can resurrect #1026?

[RomanMinkin]

Interested in this scenario as well, @dbkegley @sdrozdkov. Hope #1138 or similar solution can be landed sometime soon.

[fishioon]

+1 for this.
@ericchiang we have two connectors, one connector support 'A' client and one connector support 'B' client.
When 'A' client auth, we want use certain connector not show all connectors.

Hope #1138 or similar solution can be landed sometime soon.

[sanjeevchopra]

+1
@ericchiang - In my case, the project has a business requirement to provide it's own local user management and an option to use external IdPs, for which it is using dex. So, it needs it's own login page to have the custom authn as an option. In this case, it will be a poor experience if the user has to do the selection first on the custom login page and then on dex login.

Regarding your questions, here's my take:

We've consider this in the past, but this has a lot of implications and questions around guarantees. Should it be a scope? Client configuration? Should a user be able to change this value? Do we have to guarantee that the user can't use other connectors? Can an end user see the other connectors? Would a client be surprised if they used this feature and a user logged in through a different connector?

• This functionality is a way to select a connector through API vs UI, which already exists. Therefore, imo, it does not need any new configuration. My answer is no to all the questions above.

Thanks for your consideration!

[derberg]

@ericchiang Hey, this one looks like a feature that many people from different projects look at. Any thoughts?

[dselyuzhitskiy]

@ericchiang, we interested in this feature too. Has several ldap connectors to the same server to provide different group search based on client_id.
May be it will be more useful if it will be possible to specify connector in staticClient configuration ?

[lzecca78]

hi, my usecase is the following: bind different ldap groups to different services in order to allow some user to login in certain service and others users in other service. I guess that this can be achieved defining multiple connectors in dex, but then how to refer to them in the ingress ?

[andrejvanderzee]

+1

[bsctl]

+1

[Hedingber]

+1

[qube222pl]

+1

[MrJacek]

+1

[stefansedich]

+1 bump, this feature would be real useful to me right now, I want to have different GitHub connectors with team assertions and then specific apps use team specific connectors.

[pbochynski]

It won't happen. Let's admit it and close the issue.

[nabokihms]

@pbochynski Hello. I think we already have what you want in dex.
It is possible to bypass the connectors choice screen by redirecting a user to /auth/{connector_id} instead of /auth.
Is it solves your case?

[PrakashW94]

@nabokihms HI, I'm trying to implement a solution that redirects clients to /auth/{connector_id} to select a specific connector but it returns a 500 response.
I can see from 07a77e0 that it's possible to add the connector_id as a query string param into the /auth endpoint and have successfully tested this. Is there something I'm missing to be able to select the pass in the connector_id as part of the auth url?

[nabokihms]

You are right! Sorry for misleading 😅 The right way to select a specific connector is to pass its id as a query parameter.

[sourava01]

@nabokihms Hi, can you please point me to the docs link for this? I want to implement this but cant find any related material.

[AstritCepele]

For some clients it its not possible to implement it since their backend checks for path /.well-known/openid-configuration.
. /well-known/openid-configuration is only available on the root dex issuer.

[aaron-arellano]

Agree with @AstritCepele above, this is not a good solution when utilizing open source clients that check for . /well-known/openid-configuration ... I modified the logs in dex to show this issue in practice when I try to pass the connector_id via query param from an open source client.

400 Bad Request: <!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <title>dex</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link href="static/main.css" rel="stylesheet">
    <link href="theme/styles.css" rel="stylesheet">
    <link rel="icon" href="theme/favicon.png">
  </head>

  <body class="theme-body">
    <div class="theme-navbar">
      <div class="theme-navbar__logo-wrap">
        <img class="theme-navbar__logo" src="theme/logo.png">
      </div>
    </div>

    <div class="dex-container">


<div class="theme-panel">
  <h2 class="theme-heading">Bad Request</h2>
  <p>Connector ID does not match a valid Connector: okta-argo/.well-known/openid-configuration</p>
</div>

    </div>
  </body>
</html>

[fontexD]

+1 for this feature :D