Misleading Login Screen about zitadel HOT 9 OPEN

Hi @jiatao99
Can you please describe your use case?
I do not really understand what your problem is and what you want to achive.

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.
This means that a login screen basically belongs to an organization and is also configured there (behaviour such as idp, mfa and branding).
We do provide the possibility to tell that you want to show the branding configured on the applications organization, but not login configuration as this belongs to the organization.

from zitadel.

Hi,

The usecase, org1/project1/app1 has the setup (described above). Highlight:

1. Org1 has google as well as custom IDP. Org0 only has google
2. Org1 allow user register. Org0 does not allow register
3. Uses from Org0 been granted access to org1/project1/app1

I tried two approaches:

1. login url include special scope: urn:zitadel:iam:org:id:[org0]. Zitadel behavior:

   • app1 login shows up. With both IDPs and registration link
   • users from Org0 are NOT able to login either by password or by IDP

2. login without the scope, Zitadel behavior:

   • login screen for org0 shows up (with org1 branding - logo).
   • only 1 IDP shows instead of 2
   • user are not allow to register.
   • user from Org1 are able to login and roles are assigned properly.

My suggestion, using approach 1, but allow user from org0 be able to login

Thanks

from zitadel.

Hei @jiatao99
Thanks for the information but it was actually not what i was looking for.
You sent me the setup and what you want to have.

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.
Users of different organizations should be able to authenticate.
Users of org0 should be able to login with google and are not allowed to self register
Users of org2 with google and with azure ad are able to self register
The branding of the login should always be the same and not specific to an organization

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?
And where do you see the problem at the moment?

from zitadel.

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

from zitadel.

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.
Let me ask another question.
What happens if a user of org0 then clicks the button of the custom idp?
The reason why we implemented ZITADEL this way is that the organization does have full control over their users.

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.

from zitadel.

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

1. What if in the future, we have another org2?
2. What's happened when user trying to access org0?

from zitadel.

It should not be a problem to have another org.
If you always have a default org thats giving how the login looks like.
What do you mean by trying to access org0.
A user always authenticates on its own org at the end. As the login is bound to the orgaization and not to the application. This won't change in ZITADEL as it is one of the core points how ZITADEL is designed and works

from zitadel.

Let me make it clear for the use case:

1. org0 holds all the internal users.
2. org0 developed an app for external business. It was setup using org2.
3. internal users in org0 should be able to access org2 app using user grant
4. Login screen should display org2
5. Uses grant access in org0 should be able to login ---- This is NOT working

from zitadel.

I think I do understand your use case, you do want to define by application how the login should look like.
But I have to admit this is not how ZITADEL is designed and how we implement our hosted login.

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.
You can find some information how to implement your own login here: https://zitadel.com/docs/guides/integrate/login-ui

from zitadel.