Overview

Depending on the purpose of your portal, its visitors can play different roles. Some of them will be just browsing the portal site to get more information about your company and its services. Others, like your customers, would need to access secure content. And then there will be content managers and administrators, responsible for keeping the portal design and content, both static and dynamic, in check.

Role Description
1-anonymous-user Anonymous A site visitor who has not signed in. While you might have some information about them like their IP address, or the browser they are using, there is no way to identify a person.
1-authenticated-user Community Members, Customers, Partners, Employees Your portal target audience, either external or internal. They use the portal to access protected information (such as company reports or confidential knowledge articles), or interact with the portal and access specific Dynamics 365 data, such as their support cases.
1-content-manager Content Managers Publish and manage the site content and, to a certain extent, design. It's common for content managers to have a license to access to Dynamics 365, for example to publish knowledge articles.
1-administrator Administrators Keep the portal up and running, responsible for all aspects of the portal. Often work together or fulfil the duties of content managers. Administrator usually would have a Dynamics 365 for Customer Engagement license assigned to them.

But what about consultants and developers, people who actually designed and built the portal? Yes, they usually have a portal login, and a Dynamics 365 for Customer Engagement license. But they don't visit or use the portal in the same way as the others. When they do (for example, a developer might use an internal HR portal to submit a vacation request), they are a different kind of user and fall into one of the roles above.

Anonymous users are not associated with a contact. Their interactions with the portal, like page visits, can be recorded but the information stored does not have any identifiable pieces of information. From the portal perspective, one anonymous user is indistinguishable from another.

Authorization

When a visitor signs in, it's always associated with a contact. After that, 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 - Is the user authorized to access a specific page? Can they edit it?
  • Website authoring - Can the user edit global properties like navigation?
  • Content publishing - Can the user publish the pages or only author them?
  • Blogs, forums, and ideas - Can the user be an author, moderate, and vote?
  • Knowledge articles - Is the user authorized to access certain articles that, for example, may require a special subscription?
  • Dynamics 365 / Common Data Service data - Is the user allowed to access entity data? If yes, can they read and also update entity data? Is access limited to the records related to them, for example, only the cases that the user has created?

Dynamics 365 security

It's important to differentiate between portal security and Dynamics 365 security. They are not the same and are not interchangeable. In majority scenarios, portal audiences are external, and would not be Dynamics 365 users.

Internal portal users, for example in an employee self-service portal, would need to have a Dynamics 365 license. Commonly, content managers and portal administrators are Dynamics 365 users as well. But when they access the portal as authenticated users, they are still associated with a contact and not with their Dynamics 365 login. Their security role in Dynamics 365 plays no part in determining what are they authorized to do in the portal.

The current focus is on the content security that governs the static content of the portal and not where the content is generated based on Dynamics 365 and Common Data Service data.