pnp
New command: Ensure that the particular Azure AD app registration exists and updates its properties if necessary
Usage
m365 aad app ensure [options]
Description
Ensures that the particular Azure AD app registration exists and updates its properties if necessary
Options
| Option | Description |
|---|---|
--manifest <manifest> |
Azure AD app manifest as retrieved from the Azure Portal to configure the app registration from |
Additional Info
The command is a combination of aad app get, aad app add and aad app set.
This command checks if an Azure AD app registration with the specified ID exists.
If no Azure AD app registration is found, this command will create one using the information from the manifest.
If an Azure AD registration is found, this command will update its properties using the information from the manifest.
@waldekmastykarz
aad app add command ignores both , 'id' and 'appId' if provided in the manifest
https://github.com/pnp/cli-microsoft365/blob/55e5dfb910c3abcede4db24cb29b041052a61ada/src/m365/aad/commands/app/app-add.ts#L175-L180
So if we don't find the 'id' property in the provided manifest of the ensure command, do we first try to get the app using 'appId' property (if present) or straightaway consider the execution as a new app creation ?
I'd say we consider the app non-existent and consider new app creation. As far as I know it's not possible to create an app with a predefined objectID or clientID so in that sense they're equal and checking either one is sufficient.
ok @waldekmastykarz we will go with only 'id' as required in the manifest to determine existing app.
Also, if multiple 'identifierUris' are provided in manifest.json, aad app add command configures all, however, aad app set command only accepts a single --uri and replaces all the existing identifierUris with the one specified.
This way, the set operation of the ensure command will not configure multiple identifierUris (not sure what could be the use). Should we stop the command execution if there are multiple identifierUris in manifest ?
@vipulkelkar in the Azure Portal it seems like you can configure only one application ID URI. Do you mean redirect URI for auth by any chance?
@waldekmastykarz yes, we can configure one from the 'Overview' and the 'Expose an API' page. The identifier URI in the app manifest is an array. When we provide multiple URLs, seems like it sets the latest string from the array as the AppId URI that we see on the overview page of the App in Azure portal, however, in the manifest, there are multiple URI's configured
On trying to fetch the token, it works with both the URIs as resource URLs
Azure Portal also allows to append more URLs in the array from the 'Manifest' page of the App
Good find! I think we should consider the manifest as the desired state, so after running the ensure command, the AAD app you get should match what's in the manifest.
aad app set only accepts a single --uri. So if we use set command in ensure, we will not be able to configure multiple identifieruris to ensure the manifest desired state.
Should we first extend the set command to accept comma separated URI's ? (similar to --redirecturis parameter ).
Looking at what's in the manifest vs. what's exposed as options on the aad app set command, I think we might want to rethink how we want to implement it. If we want to let it use the aad app set command internally, then perhaps we should extend that command with the ability to pass the whole manifest rather than specific options
Using the set command as-is in ensure makes sense. My vote is to extend set command to accept the manifest.
@waldekmastykarz Should I create a separate issue to extend the aad app set command to accept manifest ?
created #3153 , we can put this one on-hold for now till the other one is implemented.
Hi @vipulkelkar, I see the issue this is waiting for has been closed as completed in v5.4 of the CLI.
I'll remove the on hold here. Are you still planning on working on it?
Hi @martinlingstuyl , this issue is waiting on #3153 as mentioned above, which is still in progress. . The mention of #3333 (which originated from this issue) might have caused the confusion.