Dynamics 365 Portals has seen some great improvements and is rapidly becoming a cornerstone for a majority of Dynamics 365 Customer Engagement implementations. Portals are used to set up an interactive web-based sales, services, support, and social engagement application platform to connect with the customers, engage communities, manage site content, and empower your channel partners. Once you have identified the general scope of what your portal will be, you will want to start to design the security model that protects it.
Dynamics 365 portals include capabilities to secure access to different parts of the portal content based on the target audience and relationship to the content. Portal security governs both visibility and management of specific content such as individual pages or the entire sections of a side. Keep in mind that portal security is different than Dynamics 365 CE security and they are not interchangeable.
Depending on the purpose of your portal, visitors can play different roles. Below is a list of different roles.
Portal Visitor Roles
Some visitors browse the portal site to get more information about your company and its services and do not sign in.
Community Members, Customers, Partners, Employees
These site visitors are your target audience, either internal or external. They use the portal to access protected information or interact with the portal.
They publish and manage the site content. It is common for them to have a license to access Dynamics 365.
They keep the portal up and running, and are responsible for all aspects of the portal. They often work together with the Content Managers and typically have a Dynamics 365 license.
When a visitor signs in, it is always associated with a contact. Dynamics 365 Portals uses a number of entities to define authorization, that is, what a user is allowed to do. The authorization process covers access to pages, website authoring, content publishing, blogs, forms, ideas, knowledge articles, and Dynamics 365/Common Data Service data.
Create Web Roles
After a contact has been configured to use the portal, it must be given one or more web roles to perform special actions or access content on the portal. For example, to access a restricted page, the contact must be assigned to a role to which read for that page is restricted. To publish new content, the contact must be placed in a role that is given content publishing permissions.
To define permissions, a web role can be associated with the following records:
- Website Access Permissions
- Web Page Access Control Rules
- Publishing State Transition Rules
- Ideas, Blogs, Forums Permissions
- Entity Permissions
A portal contact can be assigned one more web role at a time.
An account can be assigned one or more web role. All contacts under that account will inherit the role assigned.
These can be associated with a parent account and a set of web roles. When a contact accepts that invitation, they will be assigned the account and web roles.
Web Roles also include Anonymous Users Role and Authenticated Users Role which allows you to apply permissions and access rules to all portal users based on whether they access the site anonymously or if they are signed in. Contacts do not have to have the Authenticated User Role assigned.
Now that we have covered the concept of web roles, let us see how they can be used to shape permissions for the portal.
Control Webpage Access for Portal
Web page access control rules are records that you create for your portal to control both the publishing actions that web role can perform across the pages of your website and to control which pages are visible by web roles. When you create a web page access control rule, you need to specify the Web Page and the Right. Once you have created a new access control rule, you can associate it with one or more web roles.
There are two types of access control rule: Grant Change and Restrict Read
Grant Change allows a user in a web role associated with the rule to publish content changes for this page and all child pages of this page. Grant Change takes precedence over restrict read.
For example, you might have a News section on the site, which you want to be editable by users in the News Editor web role. These users might not have access to the entire sit, and certainly cannot edit the entire site, but within this branch, they have full content publishing authority.
Restrict Read is used to limit viewing of a page and its child pages. It is a restrictive rule that restricts the action to a limited set of users.
For example, you might have a section of the site meant to be used by employees only. You can restrict read access of this branch to only people in the Employee web role.
Website Access Permissions is a permission set, associated with a web role, that permits front-side editing of the various content managed elements within the portal other than just web pages. Once the grant change right is applied to a page, users in associated web roles will be able to edit the page and set properties. These website access permissions are defined on a per-site basis. It is not possible to enable and disable these permissions selectively for an individual page where the grand change right applies.
We have covered the fundamentals of Dynamics 365 Portals security. Portal features provide out-of-the-box flexibility that allows you to build robust, versatile portals where security can be configured to satisfy even the most complex business requirements when it comes to the content. Subscribe to our blog to learn more about Dynamics 365 Portals along with other technology and Dynamics information.