-
Notifications
You must be signed in to change notification settings - Fork 452
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
Misleading Login Screen #7980
Comments
Hi @jiatao99 Some things to clarify. In ZITADEL the user always belongs to an organization, the organization is the owner of the user and also defines what requirements a login has. |
Hi, The usecase, org1/project1/app1 has the setup (described above). Highlight:
I tried two approaches:
My suggestion, using approach 1, but allow user from org0 be able to login Thanks |
Hei @jiatao99 What I try to figure out what exactly you are trying to do. There might be a solution to your problem that already exists and I might be able to help you figure them out. So what i understand, you do have an application in a b2b use case. Is this correct? Do you have something to add? Can you maybe also tell what kind of users are those in the organizations? is it end users or are they managed by a company? |
My expatiation is that if an app is registered inside the org1, the login screen should be always the same as the org1. For example, org1 allow self register, it should display it (self registered user will be in org1 ONLY), Branding should be org1, external IDP should display from org1. At the time of login, since the user from other orgs already been grant the permission, it should be also be able to login Hope that make sense |
Ok I understand. Maybe something that works for you, per default we do show always the login screen of the organization that is marked as default organization. if you put org1 as your default organization you will not have to send a scope, and all users will be able to authenticate. |
For use of org0 trying to access custom IDP, it is up to IDP to give back the authentication info. As far as the custom IDP authenticated the user, it should be trusted and mapped, right? (BTW, the auto map user for IDP seems not working somehow) Make org1 as default might be a workaround. But
|
It should not be a problem to have another org. |
Let me make it clear for the use case:
|
I think I do understand your use case, you do want to define by application how the login should look like. However you do have the possibility to implement the login UI for your needs by using our session API. With that you are completely free on how your login should look like and can fully customize it. |
Preflight Checklist
Describe your problem
This is my setup:
Behavior when access login for org1/project1/app1
Describe your ideal solution
Two suggested solutions:
Version
2.4
Environment
Self-hosted
Additional Context
No response
The text was updated successfully, but these errors were encountered: