azure - What is the behaviour when publishing a single-tenant Open ID Connect application to the EntraID Gallery? - Stack Overfl

admin管理员组

文章数量:1390822

I've gone through the exercise of creating a multitenant enterprise application using OIDC on EntraID, and I understand the behaviour. Whilst, I haven't gone through the process of publishing it to the gallery, I know what the behaviour in the customer's tenant will be, and what they have to configure as I can test this via using the consent URL. I see that the user in the customer's tenant has no control at all over the app registration where I define the redirect URLs, tokens to issue, app-roles, etc.

However, I do not know what the behaviour would be if I were to publish a single-tenant Open ID Connect application, as listed here, where the documentation reads

If your application requires additional per-instance configuration, such as customers needing to control their own secrets and certificates, you can publish a single-tenant Open ID Connect application.

What is the difference between this approach and allowing a user to create their own app registration and enterprise application? What is configurable and what is not?

In my case, I'm interested in allowing the customer to define their own roles, but preferably not their own redirect URLs or what goes in the tokens, etc.

Is there anywhere I can test this behaviour? I'm assuming that some things are not allowed to be controlled by the customer user, e.g. documentation links, terms of service URLs, etc. But I can't see this documented anywhere so I'm going in blind.

I've gone through the exercise of creating a multitenant enterprise application using OIDC on EntraID, and I understand the behaviour. Whilst, I haven't gone through the process of publishing it to the gallery, I know what the behaviour in the customer's tenant will be, and what they have to configure as I can test this via using the consent URL. I see that the user in the customer's tenant has no control at all over the app registration where I define the redirect URLs, tokens to issue, app-roles, etc.

However, I do not know what the behaviour would be if I were to publish a single-tenant Open ID Connect application, as listed here, where the documentation reads

If your application requires additional per-instance configuration, such as customers needing to control their own secrets and certificates, you can publish a single-tenant Open ID Connect application.

What is the difference between this approach and allowing a user to create their own app registration and enterprise application? What is configurable and what is not?

In my case, I'm interested in allowing the customer to define their own roles, but preferably not their own redirect URLs or what goes in the tokens, etc.

Is there anywhere I can test this behaviour? I'm assuming that some things are not allowed to be controlled by the customer user, e.g. documentation links, terms of service URLs, etc. But I can't see this documented anywhere so I'm going in blind.

• azure
• oauth
• azure-active-directory
• openid-connect
• microsoft-entra-id

Share Improve this question Follow asked Mar 12 at 12:15 Summer FeelingSummer Feeling 10344 bronze badges 4

• So you want users not to configure redirect URL but add roles? – Rukmini Commented Mar 13 at 8:56
• Posted the answer please check the below:) – Rukmini Commented Mar 13 at 16:57
• Any update on the issue? – Rukmini Commented Mar 17 at 17:04
• Added a clarification to your answer below @Rukmini – Summer Feeling Commented Mar 19 at 16:05

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 1

I'm the product manager that worked on the single tenant OIDC gallery feature.

When publishing into the gallery, you are able to pre-populate information such as reply URIs, terms of service links, needed permissions, etc.. You can think of this as a step you take to help simplify the onboarding process for your customers -- instead of a multi-step process for them, you've prefilled information that they no longer need to configure themselves, and they can get all that goodness with a click of a button.

In its current state, the customer will get full control of the app registration and service principal that will be instantiated within their tenant. This information could be changed by the customer (i.e. there is no block preventing them from doing so) so keep that in mind.

Hope this helps!

Erin

Yes, I agree with you. When you create a multi-Tenant application, the user from the any other tenant will not be having access to the App registration.

When another tenant user logins into the application, the instance of the application will be present in the user's tenant under Enterprise application:

Hence the user from any other tenant will not be having access to App registration.

• The configuration, including redirect URIs, tokens, and app roles, is controlled by the application developer/administrator.

Microsoft Entra Single Tenant application allows the admin to configure and have access to the application. Not all users can access the application.

• Not all users can access the application, only the user with valid role like application developer/admin can configure and access the application.

The user with no role will get the error:

It is not possible to allow users to define their own roles, but not their own redirect URLs or what goes in the tokens.

• If the user is able to define their roles, then the user will be having control over the application too and hence the user can configure redirect URLs also.

Therefore, If a customer wants to control roles within the app (e.g., defining app roles), they need to have the appropriate admin privileges. These users can configure roles, but they cannot modify settings like redirect URLs, token claims, or other application configurations. This is because those configurations are tied to the app registration itself, which remains under the control of the developer/admin.

本文标签：