Before doing a deep dive in an organized way of the portals security model i want to say lot of this content is coming from Microsoft's documentation that you can visit in https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals its probably the best place where you will get the most up to date information available. I have created this blog entry from my walk-thru trying to get more familiar with the Portals Security model which can be a bit challenging when starting to work with.

The security model in Dynamics 365 Portals is contact centric, what this means is that each authenticated user within the portal are associated with a contact record in Dynamics 365 Customer Engagement. For example when an external user registers on your portal, that will create a contact or when a internal user that already exists in Dynamics 365 CE authenticates using its credentials (Azure AD authentication) a contact record will also be created for the user.

Its your normal contact entity record, although to make simpler to get all the Web Authentication information that needs to be configured, the solution provide you with a form (Portal Contact), that will only display the relevant information for Dynamics 365 portals, within this forms command bar, you will have options to reset passwords or create invitations (that can be customized) for users to access the portal with their details, apart from all the relevant information.

Each user will need what is call a Web Role associated with its contact record, this will define what is this user able to do within the portal, what can they see, how they can access data and what level of access they will have, etc... How this is controlled is what i will explain in the next lines.

Authentication

Right so the first thing you need to figure out is what kind of authentication you are going to be providing to your users, and how are these going to be able to register within the portal.

There are two options for this:

• Local Authentication, this works out of the box, and basically it uses the information stored in the contact record for that users to authenticate, things such as the user or the password hash are stored in the record itself.
• Federated Authentication, you will need to configure this to use external providers are, and setup the authentication mechanism between the two (Portal and your provider), this is basically if you want to allow for example your users to authenticate using their gmail account for example.

Out of the box with templates such as the Employee Self Service template you will get as well the Azure AD authentication where the federation with your domain will be setup automatically, and your users will be able to authenticate using their Azure AD credentials.

In regards on how to register you can choose either to have an open registration where users can register using a registration form or by using their accounts with your external providers, or you can also invite existing contacts you might have by creating an invitation that can be customized by editing the workflow that gets triggered when using the button in the command bar.

Authorization

Ok so once we have seen the different ways to authenticate to the portal itself, next step is to authorize what content a user can see, what actions can users do on the pages, what data and from what entities can he or se get access to. If you come from a Dynamics 365 background which is likely the case, this is what you would be doing with your security roles for example, the thing is since Portals is contact centric and obviously has other special characteristics that Dynamics 365 CE doesn't, its done in a different way, lets see how its done.

Web Role

Ok so now we have our contacts, we need to provide them with the rights to perform specific actions, or access to protected content within the portal, the association with these permissions is done thru the Web Role. So think about Web Roles as a middle entity that associated users with the different permissions that can be provided.

These permissions are the following:

• Web Page Access Control Rules control both publishing actions and page visibility across the portal for the different users.
• Website Access Permissions can provide the permissions to the role to permit editing thru the content management tools within the portal.
• Entity Permissions are what will control what can users do or get thru Entity Forms, Web Form and entity lists. Also other things such as search or templates rendered via a custom URL providers are controlled thru Entity Permissions.

Web Page Access Control Rules

Web Page Access Control Rules, is what we can use to restrict access to a certain page or group of pages that are child pages of another page, we can also do the same to provide access to make users able to change pages (although this will always require the users to be logged in).

The most important fields you are going to need to complete are:

• Name which will identify the rule when looking for it in lookup fields for example, make this easy to identify something like "Restrict access to Test page"
• Website this rule is going to be linked to, make sure you select the correct one.
• Web Page is the page you want to restrict the access to or grant change permissions to.
• Right is where you can chose whether to restrict or grant change permission.
• Scope allows you to chose whether you want this rule to impact the page itself or all its child pages as well.

Keep in mind one thing, all pages when created will be accessible (anonymously or for registered users) unless they are impacted by a rule that restricts read, and this doesn't necessarily mean to have a rule that points to the web page directly, it can also be impacted if there is a rule on its parent pages with an all content scope, hierarchy is one thing to take into considerations with Access Control Rules

If you create a rule to restrict read for a page and not even assign this rule to a web role:

• Anonymous users automatically will not be able to view the page and get forwarded to log in form.
• Registered users will not be able to access the page a message saying they are not authorized to view it. Unless they get assigned a web role that provides the restrict read access control rule to the page or one of its parents with a "All content" scope.

To me the naming convention of the Right "Restrict Read", can cause a bit of confusion, once the Security Access Control is created access will be restricted to the page unless the users get assigned a web role that has this rule in it, therefore it restricts read access to just the users that have it.

Website Access Permissions

WAP as i will called them from now on, are permission sets that can be associated to web roles, that allow front-side editing to various elements apart from normal web pages. The permissions set that can be enabled by a WAP are the following:

• Manage Content Snippets gives the permission to edit content snippets that are added to the page, such as the footer, sidebar, header, those content containers that are not the localized content of the page as such.
• Manage Web Link Sets allows editing of the menus in the pages, since these are not content snippets, with the previous permissions you will not be able to edit the menus, you will need this permission to do so.
• Manage Site Markers allows the editing of the hyperlinks that use site markers. Although i have tried i haven't found where is the difference or what extra functionality this adds in the front-side editing tools. Will update this part if i find it.
• Manager Unpublished Entities allows to view and edit if you have the permissions content that is still not published. For example if you put a page on draft state, this permissions determines whether the role will have access to it or not.

There is not much more i can say, although i do want to make one remark, about the editing permissions, for example editing content snippets, will not be possible unless the users have an access control rule that give the "grant change" right, then user will be able to edit the page and all the snippets as well.

Make sure you choose again the right website and that you assign this to the proper web role the users have.

Entity Permissions

When using Entity or Web Forms or Entity Lists, we are displaying information from CRM in our Portal, what the user is capable to see or do thru those Lists or Forms is determined by the Entity Permissions. If you are familiar with Dynamics 365 CE, this will probably be a bit strange to you to begin with, since this is not controlled by security roles at all, this means an anonymous user can access all your accounts if you are not careful.

Right the first data you are going to be asked to complete is the name and the entity you want to create permissions for, you have a nice drop down there that will display all the entities in your metadata, apart from that you will need to chose the Web Site you are creating this permission for and lastly the scope of the permissions, lets have a look on what are the different scopes for, when i say users i mean obviously users that its contact record is assigned to a web role that is associated to the entity permission:

• Global gives users access to all the records of the defined entity we specified few fields above.
• Contact this can be used assuming the entity you chose above has a relationship with the contact entity, if that entity has a N:1 relationship with the contact entity, then the users will have permissions over the records related to its contact record thru the relationship.
• Account works in a similar way as the contact, but in this case with a relationship with Account entity, this means the users will get the permissions to those records related to any account, where that account record is related to the contact record of the user.
• Self provides permissions for the user over its own contact record, remember all users in the portal will have a contact record, this scope is for permissions over that record on entity or web forms. From what i can see this is not used a lot since the out of the box Profile Page, already has a built-in form that doesn't require you to provide any permission.
• Parental is the case in which the permissions are granted for entities that are "one relationship" away from another an entity for which there is already an Entity Permission created. To have a better understanding of this scenario imagine you want to get permissions over tasks related to leads, you have access to the leads already thru an entity permission that gives you global access to them, you can create a child entity permission using that entity permission as parent, specifying the relationship between task and leads, and get the permissions inherited thru the parent entity permissions, you can also use contact-scoped permissions to only be able to access the tasks that are related to the leads the users has access to.

Last but not less just a brief mention around the different privileges that can be provided thru the entity permission, these are similar to what you get in a security role already and that you are familiar with: Read, Create, Append, Write, Delete and Append To. Depending on what kind of action you are doing you will need one or the other, if you are trying to create a record for an entity thru an entity form in insert mode, you will need create permission over that entity to be provided by one of the entity permissions your web role will be associated with.

Cool thing is portals will hide create, delete, etc... buttons that the UI might provide depending on your entity permission. One other important thing you will probably hit when working with entity lists or forms for example, is that if you are working with entity lists or forms and you dont see any impact from your entity permissions is because you probably haven't enable them to use Entity Permissions:

Please let me know if you dont agree with anything you read here, or if you have any questions feel free to drop a comment to discuss about it, again this is nothing official just what I got from playing with it, so it might get outdated in a near future, but will try to keep it updated. If there is any other topic that you would like me to provide more input or experience on let me know as well!

Thanks all!