Create Application with Secret

[rajyraman]

When I try to create new application with secret using the template below

resource clientApp 'Microsoft.Graph/applications@beta' = {
  name: 'ExampleClientApp'
  displayName: 'Example Client Application'
  passwordCredentials: [
    {
      displayName: 'Example Client Application'
      startDateTime: '2023-10-07T01:59:05.222Z'
      endDateTime: '2023-10-07T13:00:00.000Z'
    }
  ]
}

I get this error

New password credentials must be generated using service actions.

How do I create new App Registration with secret?

[pamelafox]

I am a fellow beta tester, not the team writing the types. I was recommended to use certificates instead of passwords, since passwords can't be created via Bicep and they are not the best practice security-wise. I'm currently trying that approach now.

[dkershaw10]

@rajyraman Thanks for the feedback. Pamela is spot on here. This quick-start example shows the use of a cert key instead. In following the instructions myself, I have noticed they're not the most straightforward, so I'll make an update there.

We're also looking at supporting federated identity credentials in the future.

[rajyraman]

@dkershaw10 @pamelafox - I was hoping to use this to replace pac admin create-service-principal. This command creates new App Registration with Client Secret. Right now I am using azd post hooks to do this, but doing this via Bicep itself would be optimal.

[Tapanila]

Even if the certificate is recommended way it would be amazing for this tool to support creating password authentication.

We have multiple external tools which only support Azure AD service principal authentication with password and don't have option for certificate.

Also I would be very interested on creating password rotation automation using bicep and get rid of our PowerShell things.

[dkershaw10]

Thanks @rajyraman and @Tapanila - this is really valuable feedback. We'll take another look at this and see if anything is possible here.

[dkershaw10]

@rajyraman @Tapanila I do want to temper any potential excitement here. After conferring with one of the engineering managers, he's less than enthusiastic about enabling this. I think it's really unlikely that we'll end up supporting this, mainly because it's not particularly secure.

I understand that this makes things very problematic for existing external tools that only use client secrets, but we really want to point developers to more secure ways of doing things rather than perpetuating an insecure mechanism that creates more long-term security debt.

[Tapanila]

@dkershaw10 sad to hear that. Is it unsecure to set/create password credentials with this or generally using password credentials?

[sopelt]

In a perfect world: MSI all the things and never look back! ;)

Nowadays with workload identity federation ... there is a really high probability that secrets can be avoided for such scenarios ... one of the only missing puzzle pieces would be cross tenant WIF ... ;)

[Petermarcu]

One of the primary reasons for needing this support in ARM was to enable people to do app registration purely using ARM/Bicep. Bicep is sent to the service in a single, one shot deployment including all Azure resources.

In the world of an ARM/Bicep deployment, it is very possible that the KeyVault is also part of the resource deployment and therefor there is no opportunity to put a certificate in a keyvault and this means the app registration cannot depend on a certificate in the keyvault. Not to mention the fact that creating certificates is a non-trivial task for developers, especially on Mac and Linux.

Do we have an example of how someone can do this? Can we get an example of how someone creates an app registration in an empty subscription using a Bicep deployment?

[Agazoth]

I will just post my 2 cents here after going public.

According to documentation and linters, MicrosoftGraphPasswordCredential is supported. Nothing warns about this feature not working.

If the reason for this feature not working is, that it implies a security risk, the functionality should be removed entirely from the resource. But that is very unlikely.

Virtually all code samples for cloud native apps in Microsoft Learn use ApplicationId and ApplicationSecret for the code running on WebApps, Azure Functions etc. Marking this routine as "less secure" does not justify keeping inoperative code in the template.

Most deployments run from pipelines that never log the secrets anyway. Hence a Microsoft.Resources/deploymentScripts script, that generates a secret tor the serviceprincipal and places it in a key vault (as is usualy done for the deployments anyway) is just as secure as a certificate in automated deployments running in CAF aligned tenants.

This brings the discussion down to: Microsoft.Graph/servicePrincipals does not support passwordCredentials.

Without looking at the code, I can imagine, that the addPassword bit has not been implemented in the provider. If there is a backlog item for getting the functionality into the provider, and that task is immanent, it makes sence to keep the code as is. If not, the passwordCredentials parameter should be removed from the Microsoft.Graph/servicePrincipals resource.

To support the scenarios where Devs and IaC teams are not close enough to adjust the code to use certificates in stead of secrets, it ould be great with a sample deployment that supports secret generation and storage in key vault along the lines of the certificate sample.

[dkershaw10]

Hi @Agazoth - thank you for your comments, which are all valid. The Bicep resource types exposes the underlying Microsoft Graph type. We can look into whether we can remove the passwordCredential property, as passwords cannot currently be created via application create/update.

There were two main reasons we did not enable app passwords/secrets:

1. addPassword is a service action, and we haven't worked out a good way to expose service actions (as these aren't resources). Also addPassword is not idempotent. More on this below.
2. app passwords/secrets are less secure. TBH any credential is less secure.

We have a backlog item for 1 - to have the applications API team enable upsert support for app passwords/secrets (rather than using a service action). App passwords is a capability in Microsoft Graph, so it should be exposed in Bicep too, IMHO. However, that team is unlikely to fund that work with the focus on Secure Future Initiative. I have continued to push on this, as @Tapanila has repeatedly pointed out that there are some legacy apps that cannot be updated, that still use app passwords, and he'd like to manage them in Bicep.

Your point on code samples is spot on, but I suspect that this might change with the Secure Future Initiative. I'm a big proponent of password/credential-less applications. Federated Identity Credentials is a good starting point, and I'm waiting on an eagerly expected feature to use managed identities as a federated identity credential. I have an internal sample where the config is so simple, and there's no management overhead of storage in KeyVault, or rotating credentials - I'm just waiting on that feature to go to public preview, and I expect a ton of our code samples to shift to that model.

I will discuss with the team about removing passwordCredentials from application and service principal Bicep types, with the assumption that app passwords/secrets are unlikely to be supported.

In the meantime, I'll see about updating the docs to make it clear that passwords/secrets are not supported for applications and service principals, via Bicep Graph. UPDATE: @Agazoth Known issues has been updated

[dkershaw10]

For those of you interested in passwordless apps, please watch Secure your Intelligent Applications with Microsoft Entra which was presented yesterday at Build 2024. If you want to check out the bit on passwordless apps specifically (MSI as federated identity credentials) skip to 23:20 into the video, and @pamelafox gives you a sneak peak.

[pamelafox]

Here are the slides for that section: https://speakerdeck.com/pamelafox/secure-your-intelligent-applications-with-microsoft-entra?slide=31 And a diff that shows the full Bicep to create an Entra app, setup an MI-as-FIC credential, and set that as the app for the built-in authentication feature of App Service: https://github.com/pamelafox/simple-flask-server-example/pull/20/files#diff-a73e34ada5eda4cc4f95a2836ff1c8b67420a57c649add4f51e18ef572e5fca0

[mbrat2005]

@dkershaw10 Thanks for the Known Issues update on App/SP secrets!

I see the note about Deployment Scripts being a workaround to add a credential, but this suggestion seems to require the identity of the Deployment Script to have permissions to create the secret credential. With the goal being enabling this all in IaC, I don't see that we could grant an identity Entra permissions to add the client secret--unless I am missing something on the approach?

[SheaSmith]

Has there been any update on the MSI as federated identity credentials? We're quite keen to get started using it as it would solve quite a few headaches for us (and remove the last non-MI credential we have)

[dkershaw10]

@mbrat2005 Maybe I'm missing something. The deployment script is run in the context of a user-assigned managed identity which (in the template) is assigned the necessary permissions to operate on the KV and generate the certificate credential. I don't see where an Entra permission is involved for the deployment script part. There are no additional Entra permissions required to create an app with a certificate credential vs just creating an app without a credential, as far as I know.

FWIW - I totally agree with you - I really dislike the deployment script, as it's not in the spirit of declarative IaC, but none of the KV operations are currently exposed in ARM/Bicep templates. My preferred option is to go secret-less with managed identity as a federated identity credential (which can be done completely in declarative IaC), so over to Shea...

@SheaSmith I hear you and even have an MSI as FIC template sample ready and waiting for publication. I'm continually pushing the MSI team to get public preview out the door. I don't have any updates that I can share. I will try and get the product manager to comment if I can.