Active-directory - Cross domain trust with OAuth2 OBO flow

Question

Need some help in reviewing/ improving security architecture that we have.

This is kind of architecture that we have

The user login flow is KeyCloak backed by AD. When a user logins to the apring app, we authenticate him via AD, and sync the user in the Keycloak. However, for any user to be onboarded on the platform, the user has to login first.

Our keycloak is actually used by other entities as well, user still need to exist in the system even if he hasn't finished onboarding process.

Does Azure AD provide any functionality that will let us sync all the users from AD into keycloak while starting their onboarding? Any API's or export/import functionality that can help us?

Is there any alternate approach/pattern that we can follow in this case?

Any help in this regard is really appreciated.

Update This is what we are trying to build. we changed architecture a little bit. Now keycloak can exist, but primary auth brokers will be Azure AD in both cases. Here it is -

However one question remains - For seemless user experience, Organization app will need to make calls to wallet API's. To make these API calls we will need access token from Wallet AD. Considering that the trust is build, I assume that the users will be trusted. However, I am not able understand how we will aquire the token from Wallet AD without client activity.

Answer 1

We solved our usecase using delegated auth flow / Identety provider flow in Keycloak. We added two keycloaks in Wallet app and Org app both.

1. The keycloak in Org app handles delegated auth with Organization AD, so we are saved there. This flow was already in place, and user is agnostic about it.
2. Upon successful authentication on Org Keycloak, we take the user to Wallet Keycloak, where Org keycloak is setup as an Identity provider (IPA). Thus the user is taken to Org keycloak for authentication.
3. The fact that user is already signed into org keycloak, makes user already authorized, and sends him back to wallet keycloak, without any user action, and thus making it seemless.
4. With Org as IPA, user successfully logs into the Wallet app, and comes back with another token, which we store for using with wallet apis in future.

This is how it looks in reality - Please note that the dotted lines that you see in the diagram are the user actions/ redirections in the flow. I have numbered them so that its easier to understand.