Cli-microsoft365: New command: create custom AAD app for use with the CLI

[waldekmastykarz]

Usage

cli app add

Description

Creates custom Azure AD app for use by CLI for Microsoft 365

Options

Option|Description
----|----
-m, --mode <mode>|Determines if CLI will be used by a user (delegated) or as a deamon process (appOnly). Allowed values delegated,appOnly
-p, --permissions [permissions]|List of permissions to assign to the app. If not specified, will assign all permissions currently used by CLI for Microsoft 365. For the actual list see https://pnp.github.io/cli-microsoft365/concepts/authorization-tokens/#azure-ad-application-used-by-the-cli-for-microsoft-365. Use permissions or permissionSet but not both
--permissionSet [permissionSet]|Predefined set of permissions to assign to the app. Allowed values ReadAll, SpoFull, SpoRead. Use permissions or permissionSet but not both

Additional Information

• the AAD app will be created in the current directory
• the AAD app will be created using the Azure CLI Azure AD app
• the created AAD app will be single-tenant
• when configuring permissions, CLI automatically chooses the permissions to be granted based on the selected mode
• when mode selected to app-only, automatically generates a certificate valid for a year
• later, when we support persisting configuration #1945, running this command should update the config with the ID of the newly created app
• returns the Azure AD app ID and, if the selected mode was daemon, the thumbprint, password and expiration date of the generated cert

[waldekmastykarz]

@pnp/cli-for-microsoft-365-maintainers I'd love your feedback. In particular, I'd appreciate if you thought about:

• is this spec oversimplified and are we missing some cases?
• are user and deamon clear enough or do we use different names to denote the different usage modes
• is it correct to assume that in app-only mode folks will be okay with using a secret or should we use a certificate instead? If cert, why and what expiration period should we choose?

[garrytrinder]

Great suggestion! 👏 Some of my thoughts...

is this spec oversimplified and are we missing some cases?

I don't think it needs to be anymore than what it is.

are user and deamon clear enough or do we use different names to denote the different usage modes

I would prefer delegate and app, as this then makes it clear what type of permissions will be added, this is also what the Azure Portal refers to them as.

is it correct to assume that in app-only mode folks will be okay with using a secret or should we use a certificate instead? If cert, why and what expiration period should we choose?

Thinking from a best practice perspective, certificate is more _secure_ than providing a password or secret, so I think we should promote this as such. See below statement on the Certificate & Secrets blade in the Azure Portal.

Credentials enable confidential applications to identify themselves to the authentication service when receiving tokens at a web addressable location (using an HTTPS scheme). For a higher level of assurance, we recommend using a certificate (instead of a client secret) as a credential.

Microsoft have provided some guidance on the validity period of certificates based on length in the past (https://techcommunity.microsoft.com/t5/configuration-manager-archive/recommendations-for-pki-key-lengths-and-validity-periods-with/ba-p/272758).

Key length of 1024:  Validity period = not greater than 6-12 months
Key length of 2048:  Validity period = not greater than 2 years
Key length of 4096:  Validity period = not greater than 16 years

I think that one year would be a good starting point, coincidentally when creating a secret in the Azure Portal the validity period defaults to one year also.

[plamber]

Hi,
agree with @garrytrinder regarding delegated and app mode. I would extend the permissions concept by letting the use specify the service he/she wants to enable.

For example:

• ReadWrite.All (enables all permissions of the CLI)
• Read.All (enables all permissions of the CLI for read operations
• ReadWrite.SPO (enables all read and write SPO permissions)
• Read.SPO (enables all read SPO permissions

etc.

Not sure if we should have a separate parameter for this.

As return type I would also return the Azure AD Url to the app.

br,
Patrick

[garrytrinder]

For example:

• ReadWrite.All (enables all permissions of the CLI)

• Read.All (enables all permissions of the CLI for read operations

• ReadWrite.SPO (enables all read and write SPO permissions)

• Read.SPO (enables all read SPO permissions

Love this, great idea 👏🏻

[waldekmastykarz]

Thanks for your thoughts gents! Here are some thoughts:

I would prefer delegate and app, as this then makes it clear what type of permissions will be added, this is also what the Azure Portal refers to them as.

How about delegated and app-only? _mode: delegate_ sounds weird and _mode: app_ isn't quite self-explanatory.

I like the suggestion to use a cert instead of a secret. I thought first of using a secret, because it doesn't expire. Since there is no reminder on expiring certs, admins are often getting surprised when things stop working. If we were to use a cert, then we should return the expiration date of the generated cert.

As for permissions: there is something to say for using permission sets that you mentioned, but I would still allow users to specify their own permissions as listed in AAD. So perhaps these sets could be exposed in a separate option named --permissionSet? To make it clear that these are made up permissions, I'd also suggest using different names like ReadAll, SpoFull, SpoRead. I don't need if we need Full as that's the default setting.

[garrytrinder]

How about delegated and app-only? mode: delegate sounds weird and mode: app isn't quite self-explanatory.

Works for me 👍🏻

If we were to use a cert, then we should return the expiration date of the generated cert.

Agreed.

So perhaps these sets could be exposed in a separate option named --permissionSet? To make it clear that these are made up permissions, I'd also suggest using different names like ReadAll, SpoFull, SpoRead. I don't need if we need Full as that's the default setting.

Agreed, I like the idea of permission sets.

[waldekmastykarz]

Updated spec. Is it good to go now?

[garrytrinder]

Ship it 😊

[garrytrinder]

Actually, can we change app-only to appOnly, removing the -?

Like you said in another issue, we don't use them in option names so using them in values doesn't seem right.

[waldekmastykarz]

Spec updated. Is it ready to go?

[garrytrinder]

Ship it (again) :slightly_smiling_face: :rocket: