What is the "Client Secret" in the Engine App registration used for?

[gummigroda]

Hi,

As we are not allowed to use secrets in Apps anymore, how is this secret being consumed and what is it used for?
Are we able to replace it with certificate or better yet, a FIC or Managed Identity?

Thanks!

[gummigroda]

Hey @DCMattyG !

Have time to explain this?
Would love to use the UAMI instead of a secret 😄

[DCMattyG]

Hi @gummigroda, apologies I missed this before!

An Application Registration represents the application itself and is an integral part of the Microsoft Identity Platform. With App Registrations, they can be granted different kinds of API permissions, including permissions to act on their own (App) and permissions to act on behalf of another user (Delegated). Managed Identities do not have these capabilities and instead represent an ARM resource (such as a VM, a PaaS service, etc.)

In the Azure IPAM platform, the engine component needs to perform both operations on it's own, such as recurring tasks, but also it needs to execute API calls as the user (on behalf of). This is something you can only do with an Application Registration, and with an Application Registration comes some kind of secret for it to authenticate.

Overview of Application Registrations: https://learn.microsoft.com/en-us/entra/identity-platform/application-model
Application Registrations Permissions & Consent: https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview

TL:DR - Because this is an application that needs to authenticate users and perform operations on their behalf, we must use an Application Registration. Additionally, because it's performing actions directly as well, it requires a secret for authentication.

On-Behalf-Of Flow: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow

Hope that helped!

[gummigroda]

Hi @DCMattyG, thanks for the reply.

I should have been more precise in my ask, sorry.
I do somewhat understand how delegated permissions and application permission work with app registrations. My ask is, would it be possible to use a managed identity either system assigned or user assigned when the "engine" need to interact in "application mode" (not delegated) against Azure resources?

When running Azure functions, I'm able to assign a managed identity(SP) to it and then in code, request a accessToken from a internal endpoint. With that accessToken, I'm able to use/update Azure resources (ARG/tables/sql databases) I've delegated role assignment's to this managed identity, or access API's defined in another app registration.
Docs - here and Likewise for Azure container apps (may not be relevant)

Now, I'm running IPAM as a container in WebApps, and with a quick search, there isn't that easy to find any more specific documentation regarding this (if it's even different?), other than a really old thread on SO

What do you think?

[DCMattyG]

Ah, I understand better now. And I apologize for not realizing what you were actually asking!

Azure IPAM already uses a User-Assigned Managed Identity today. All of the services authenticate to each other via this UAMI including communications to Cosmos DB. The App Service for which the Azure IPAM code runs within is assigned this UAMI at deployment time and uses this to reach out to all related Azure services.

Is there somewhere you are seeing otherwise?

BTW, I totally agree I need to document this better and I am working on adding more granular detail to the docs along these lines.

[DCMattyG]

Just to quickly follow-up here, if you're asking if we can remove the requirement for the Engine secret, the answer is no.

The reason why is well-documented in the link I shared about as to how the on-behalf-of authentication flow works in the Microsoft Identity Platform.

On-Behalf-Of Flow: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow

[DCMattyG]

Furthermore, the Azure IPAM code could be running in a plethora of different places (App Services, Function App, Azure Container Apps, Azure Kubernetes Service, etc.) and it needs to be flexible enough to run in ALL of these places. People may even be running this LOCALLY on their laptop/desktop so you can see where using a Managed Identity for the On-Behalf-Of flow can't really support this type of paradigm.

Sorry for so many responses, just wanted to emphasize that this is something I've put a lot of time and thought into making this platform as secure as possible. That said, I'm always open to ways I can further improve things.

[gummigroda]

Thanks for the great explanation. Have to read up on the link you sent me.

Also have to kind of understand the secret usage more in detail as we have an requirement to not use secrets in App registrations.

Looking forward to the next upcoming release.

Great work!

[picccard]

Hope this gets a revisit 😅 It's not possible to eliminate the need for the app registration, but the secret can be eliminated in favour of federated credentials to a managed identity.

https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad?tabs=workforce-configuration#use-a-managed-identity-instead-of-a-secret-preview

Instead of configuring a client secret for your app registration, you can configure an application to trust a managed identity. Using an identity instead of a secret means you don't have to manage a secret. You don't have secret expiration events to handle, and you don't have the same level of risk associated with possibly disclosing or leaking that secret.

https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-config-app-trust-managed-identity?tabs=microsoft-entra-admin-center%2Cpython

Regarding the OnBehalfOf, it seems also to be updated to work with client assertions such as federated credentials:

• [Identity] Allow use of client assertion in OBO cred azure-sdk-for-python#35812
• [identity] update OBO client assertion azure-sdk-for-js#29711
• Client Assertion for OnBehalfOfCredential azure-sdk-for-net#44368

[DCMattyG]

Thanks for those details @picccard, something I can definitely look into. However, I did mention the following above:

Furthermore, the Azure IPAM code could be running in a plethora of different places (App Services, Function App, Azure Container Apps, Azure Kubernetes Service, etc.) and it needs to be flexible enough to run in ALL of these places. People may even be running this LOCALLY on their laptop/desktop so you can see where using a Managed Identity for the On-Behalf-Of flow can't really support this type of paradigm.

How would you handle this as it seems that what you've provided above really only applies to Azure App Services or Azure Functions (at this point in time) and might not apply to other types of deployments such as AKS or even the application itself running outside of Azure?

[DCMattyG]

In reading the second link you provided, are you saying this paradigm can be used in all of the above scenarios?

If so, it sounds like I have some testing to do so I can see how I can work this into things. Likely for net-new deployments but if it works can always explore some kind of upgrade process...