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: https://github.com/coreos/dex/pull/1083
Thanks for opening this!
Copying my response from https://github.com/coreos/dex/pull/1026#issuecomment-322573698
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.
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:
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.
+1 for this.
The main reason for me is to be able to have social login button nicely integrated into the application.
I did PR some time ago:
https://github.com/sdrozdkov/dex/commit/dfbabddcfa52d7c1dd8a9f14b783401d14d78a35
This functional added with param &connector to auth requests.
If need I can do needed changes for merge this.
Our team has a similar requirement to @kiich 's.
@sdrozdkov Could you make a pull request?
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
We have the same exact scenario as @dbkegley. Maybe we can resurrect #1026?
Interested in this scenario as well, @dbkegley @sdrozdkov. Hope #1138 or similar solution can be landed sometime soon.
+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.
+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
noto all the questions above.
Thanks for your consideration!
@ericchiang Hey, this one looks like a feature that many people from different projects look at. Any thoughts?
@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 ?
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 ?
+1
+1
+1
+1
+1
+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.
It won't happen. Let's admit it and close the issue.
@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?
Most helpful comment
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: