Increase trust and explain how to configure Azure AD permissions properly

[plamber]

Hi guys,
Office 365 CLI works very well for all customers that fully trust what we are doing with our multi-tenant application and the permissions requested in that app.

On the other hand, I am looking at use cases where enterprise customers are just overwhelmed by the permissions we are asking.

• Let us imagine a business unit of a customer wants just to synchronize content with SharePoint online and does not care about the rest. The application is requesting too many permissions by default.
• We might have customers that do not want to have a multi-tenant app running in our environment and just register their Azure AD application to have "more" control
• We might also have enterprises that want to configure their Azure AD instance per business unit and restrict the usage of that instance using Azure AD capabilities.

Our documentation does not explain how to tackle such use cases. To tackle this problem I would suggest working on the following topics:

• We should create more documentation on how to configure an Azure AD application and use the CLI with that specific application
• We should add for each command a permission matrix like the Graph team is doing. Nobody knows what are the least privileges for a specific command and if you can just use the command with delegate or application permissions. Without this information, people are just lost.

Let me know what you think about this.

br,
Patrick

[waldekmastykarz]

There a number of ways I could think for us to address this:

1. We use a different app with nothing but User.Read and users can add more permissions through dynamic consent. We use this mechanism for Yammer already, because it's not available on all tenants, but we could use it for everything. Upside: only the necessary permissions are granted. Downside: you need to know which permissions to request. We could help through docs, but still the default experience would be that nothing works.
2. We could extend our docs with the exact process of setting up a dedicated AAD app. We have some docs in this area but agreed that they could be better.
3. Additionally, we could introduce a command to create a dedicated AAD app for folks to make things easier. To avoid chicken and egg problems (you need AAD permissions to create AAD apps), we could leverage the existing Azure CLI AAD app or offer an Azure CLI script that folks can run themselves.

We should add for each command a permission matrix like the Graph team is doing.

This could be a good idea although we'd need to verify that it's viable across all O365. Not all APIs are as well-documented as MS Graph and in some cases it would be very much hit and miss to get the right permission set for the given command. Not saying we shouldn't do it though, especially if it can help us with adoption.

I wonder if the issue you brought up @plamber could be related to how things used to be with folks being able to use basic auth without the notion of an app. With that going away more and more and not working outside of the SharePoint realm (MS Graph only supports OAuth), I wonder to what extent it's a new reality that we have to accept, that custom apps must be registered with AAD and it's a fact of life rather than something special that we do.

[phillipharding]

I think option 2 plays well into the "bring your own application" scenario where you're working in more restrictive environments, maintaining at the same time the status-quo using the CLI's multi-tenant app.

When working in different environments you then have a choice to use the CLI with the CLI app or your own app.

[waldekmastykarz]

The reason why I brought up the ability to create an AAD app registrations is because different configuration is needed depending on if you want to use it in app-only mode or on behalf of a user. We could simplify the process, but it would be additive to proper guidance in case someone wants to or musts create the app registration themselves.

[phillipharding]

I think more detailed guidance is certainly a good idea, it's an area filled with confusion when you consider the different ways in which an app registration can be configured.

Creating an App Registration with the CLI helps along this path, and I guess it would probably be used by users with an Administration role, so even if "Users can register applications" was turned off it could still work?

[plamber]

I also had cases of customers disabling end-user consent completely to ensure users are not "misusing" apps. In such situations you have to go through an administrator, let them register the app and grant consent.

I thought in providing guidance to these use cases too.

[waldekmastykarz]

@phillipharding I don't think we could circumvent any AAD security setting, so if allowing users to register applications is disabled, that's that and there is no way around it.

@plamber we could offer both approaches and let the user decide which one they want to take. If they feel comfortable enough working with AAD, they could use our guidance. If they look for an easier way, they could use the command.

[garrytrinder]

We could extend our docs with the exact process of setting up a dedicated AAD app. We have some docs in this area but agreed that they could be better.

As this is can be a complex subject, I think we should look to create a dedicated page for this in our documentation and use a similar format to the GitHub Actions page https://pnp.github.io/office365-cli/concepts/github-actions/.

It could then start to address the concerns raised by @plamber that it is not clear why we ask for the permissions that we do as default and a detailed (working example) of how to 'roll your own' identity.

[phillipharding]

Would you envisage this being a complete step-by-step walkthrough of creating the App Registration including creation of the Certificate, cross platform (Windows?/Mac OS)?

[waldekmastykarz]

This page would need to describe each combination of Windows/macOS and app-only and delegated auth. There are subtle let important differences in setting up the app for app-only or delegated auth and we'd need to cover them. As for the OS, like you mentioned @phillipharding, creating the cert is the key differentiator.

[garrytrinder]

Yes @phillipharding, I think a walkthrough style tutorial can be aimed at our most commonly used environment, so possibly Windows and PowerShell, this will help users understand the process end to end and fully introduce a new concept that may be alien to them.

For the more OS specific elements, we can highlight these as specific How Tos such as "How to create a cert on MacOs" and link to them from the tutorial.

[waldekmastykarz]

@garrytrinder care to create an issue for this so that we can track the work?

[garrytrinder]

#1496 has been raised 👍🏻