Teams and SharePoint provisioning solutions - new Group.Create permission

It's common for organizations using Office 365 to provide a custom experience for requesting and creating Microsoft Teams and/or SharePoint sites - often giving the ability to select from pre-defined templates, provide metadata and important settings, check for a possible duplicate, implement an approval process and so on. For many, this is key part of governance and provides a more controlled approach than "allow everyone to create and perform some clean-up later". We've been building solution like this for years, and as one example, the workspace request and provisioning capability in our Fresh digital workplace solution has increased in richness and control as Teams has come to prominence and APIs have gotten better.

You want WHAT permission in our tenant??

Until recently, there was a big problem with these solutions. Since both Microsoft Teams and SharePoint team sites are underpinned by Office 365 Groups (though not SharePoint communication sites of course), creating either involves creation of an Office 365 Group underneath. Whether a logged-in user or application or tool is performing this step, a very high permission is needed - Group.ReadWrite.All. This is essentially allowing the app to read and write to any Microsoft Team, SharePoint site or Office 365 Group within your entire tenant - think about that for a moment!

As you might expect, many security-conscious organizations were reluctant to grant this permission to something running in their tenant. Practically every business on the planet using Office 365 to it's full extent has Teams and SharePoint sites which contain sensitive information, and the whole idea of a single application being able to change or delete data across the entire estate is very far away from the principle of least privilege. If an attacker or some malicious code code was to impersonate this identity, the impact to the business could be huge. 

With one global organization, I spent around 8 weeks convincing the Digital Security (Info Sec) group and other stakeholders that the other mitigations our team and other internal teams were taking were enough to offset this risk. No less than 7 distinct sign-offs were required.

So, something had to change. I knew others would be feeling this pain and I'd been speaking to folks at Microsoft like Jeremy Thake about it for some time. I finally got round to raising a request on UserVoice, but also mentioned it on Twitter. I was pleased to see this response from Bill Bliss, Microsoft's Platform Architect for Teams:

So, that gave me hope. Fast forward a few months, and the good news now of course is that a solution landed some time ago - making the lives of anyone building on the Office 365 that bit easier.

The new Group.Create permission in the Microsoft Graph

Solutions which create Microsoft Teams or Group-connected SharePoint sites can now use a new permission scope in the Graph authorization model named Group.Create. This arrived without much noise or fanfare, and I suspect many people who this is relevant to may still not be aware. 

As you might expect, this allows the user or application to create new Teams, Groups and sites, without having access to all existing instances. As the documentation says:

Allows the calling app to create groups without a signed-in user. Does not allow read, update, or deletion of any groups.

 This is hugely important for any organization using Office 365 who cares about their security posture and wants to make use of provisioning solutions. Here's what it looks like in AAD:

Hoorah! So now we have something that fits both requirements:

• Allows new Teams and sites to be created
• Minimises the surface area so that other actions cannot be taken

Call to action - is this relevant to your environment?

If you're using any kind of tailored approach to creating Teams and SharePoint sites, whether it's solution developed in-house or by a partner, a 3rd party product or one of starter solutions found on Github, you should ensure the permission set used is Group.Create. If you find there's a change to be made, this should be carefully managed with testing in your non-production tenants before being going ahead with the switch in live of course - but the process shouldn't be too complex.  

I previously mentioned this new option on Twitter a while ago, and was quite a few people responded in some way:

However, I wanted to also post about this here too. The pace of change in Office 365 and underlying platform elements such as the Microsoft Graph is relentless, and it's easy to miss things. And whilst there will always be imperfections, it's good to know that things like this are being smoothed out.

Hopefully this is useful to some folks!