In the previous article, Containers and Files Security in SharePoint Embedded, we explored the power of content permissions for controlling access to container data. But security in SharePoint Embedded goes beyond just files and containers. Applications themselves play a crucial role in managing access and functionalities.
This article dives deeper into the world of SharePoint Embedded application permissions. We’ll uncover the different types of applications, how they interact with permissions, and the various roles you can define for granular control. By understanding these concepts, you’ll be well-equipped to build secure and scalable solutions that empower your users within SharePoint.
Understanding Applications
Applications in SharePoint Embedded act as your tools for managing content and containers. Each application requires a Microsoft Entra ID identity, ensuring a secure environment. Additionally, they need specific Microsoft Graph permissions to call the corresponding endpoints.
There are two main types of applications, each playing a distinct role:
Owning Application: This application acts as the leader, directly linked to a container type. It’s responsible for creating both the container type and its individual containers. Imagine it as the architect, designing the blueprints and laying the foundation. It also has complete control over these containers and their content.
Guest Application: As the name suggests, this application focuses on managing the content that lives inside containers. Think of it as the interior designer, arranging and presenting the content within the established structure.
Knowing Tenants
The concept of tenants is crucial when working with SharePoint Embedded applications. Tenants are essentially spaces where you build your solutions on top of the containers. Here’s a breakdown of the two key tenants:
Development Tenant: This is your starting point! Here, you’ll create and configure your Container Type and assign the owning application.
Consuming Tenant: This is the final point! This is where the Container Type is used so, containers are created. All data will be under the consuming tenant scope.
Defining Permissions
Permissions in SharePoint Embedded allow you to delegate control over different aspects of your solutions to applications. They can be combined to create various user roles and organize user actions effectively.
Here’s a breakdown of the permission sets available, categorized by their scope:
Content:
ReadContent: Allows applications to read existing content within containers.
WriteContent: Allows applications to write content (files) to containers.
Container:
Create: Allows applications to create new containers.
Delete: Allows applications to delete containers.
Read: Allows applications to read container metadata.
Write: Allows applications to update container metadata.
Permission Management:
EnumeratePermissions: Allows applications to list container members and their roles.
AddPermissions: Allows applications to add new members to containers.
UpdatePermissions: Allows applications to change the role of existing members in the container.
DeletePermissions: Allows applications to remove members from containers (excluding itself).
DeleteOwnPermissions: Allows applications to remove themselves from container permissions.
ManagePermissions: Allows applications to perform all permission-related actions (add, update, remove, including itself).
There are two additional special permissions to be aware of:
None: The application has no access to containers.
Full: The application has all available permissions (use with caution).
Roles
This table provides a basic framework for defining roles with specific access levels to container content and management. You can adapt these roles further based on your specific needs and security requirements.
Viewer: Can only view the content and basic metadata of containers.
Contributor: Can view, create, edit, and delete the content of containers and read the container metadata.
Editor: Can view, create, edit content, manage basic container metadata, and see who has access to the container.
Administrator: Has full control over containers, including managing content, metadata, and permissions of other users.
Auditor: Can view container metadata and list members with their roles, but cannot access content.
Content Manager: Can view and modify the content of containers, but cannot create, delete, or manage container metadata or permissions.
Container Manager: Can create and delete containers, as well as view and edit their metadata. Cannot manage content or permissions.
Permission Manager: Can manage permissions for containers, including adding, removing, and modifying user roles. Cannot access content or container metadata.
A Real-World Example
Let’s imagine our business is an art gallery and we want to leverage SharePoint Embedded to create a solution. We want a system for artists to manage their artworks, a jury to evaluate submissions, and a public platform to showcase the art.
While it’s possible to build everything into one app, we can leverage SharePoint Embedded’s features to create a more secure and manageable solution with separate applications:
Artist Portfolio: This artist-facing application allows them to view submitted artworks, track performance metrics, and update their profiles.
Curatorial Review App: A secure application for jury members to review submissions, leave feedback, and manage roles (for administrators).
Public Artwork Gallery Website: This website showcases the artwork available in the gallery. Users can browse submissions, view artist biographies, and potentially initiate purchases (without write access for this application). There wouldn’t be a need for the public website to modify any content within SharePoint.
Assigning Permissions for Secure Access Control
Each application in this scenario will have a designated role within the SharePoint Embedded architecture:
Artist Portfolio App: This application requires ReadContent and WriteContent permissions. Artists can upload their works, view existing submissions, and update their profiles. Additionally, if the solution allows new artist registration, permissions like Create, Read, and Update might be needed for managing their own containers.
Curatorial Review App: ReadContent permission is sufficient for jury members to access and review submissions. They can also leave private feedback notes for artists. Depending on permission settings, they might have access to view other jurors’ notes. For administrators managing roles, additional permissions like EnumeratePermissions, AddPermissions, and UpdatePermissions might be necessary.
Public Artwork Gallery Website: Since this is a public website, it only requires ReadContent permission to display the artwork information. There’s no need for write access to modify content within SharePoint.
Conclusion
By understanding applications, tenants, permissions, and roles, you’re equipped to build secure and scalable solutions with SharePoint Embedded. This approach allows for granular control over user access and data, ensuring a robust foundation for your custom SharePoint Embedded experiences.
Remember, this is just a starting point. As you delve deeper into SharePoint Embedded, you’ll discover a vast array of possibilities for crafting unique and valuable applications!
References
Containers and Files Security in SharePoint Embedded: https://intranetfromthetrenches.substack.com/p/containers-files-security-in-sharepoint-embedded
SharePoint Embedded authentication and authorization: https://learn.microsoft.com/en-us/sharepoint/dev/embedded/concepts/app-concepts/auth
SharePoint Embedded app architecture: https://learn.microsoft.com/en-us/sharepoint/dev/embedded/concepts/app-concepts/app-architecture
Register file storage container type application permissions: https://learn.microsoft.com/en-us/sharepoint/dev/embedded/concepts/app-concepts/register-api-documentation
Man reading content of a filing cabinet by National Cancer Institute from Unsplash: https://unsplash.com/es/fotos/foto-en-escala-de-grises-de-un-hombre-89rul39ox2I
