© Sanjaya Yapa 2019
S. YapaGetting Started with Dynamics 365 Portalshttps://doi.org/10.1007/978-1-4842-5346-5_2

2. Portal Security and Content Management

Sanjaya Yapa1 
(1)
Mount Waverley, VIC, Australia
 
The purpose of this chapter is to guide you through the portal security and content management interface of Dynamics 365 portals. There are several approaches that you can take to configure portal security. Portal security does not work the same way as Dynamics 365 security works. The challenge is to grant the right access to resources, content, and data whether you have done an advanced configuration or a simple configuration. Therefore, careful planning must be done beforehand. In this chapter, you will learn how to configure security and when to use these configurations. Figure 2-1 is a high-level illustration of how portal security works.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig1_HTML.jpg
Figure 2-1

Overview of Dynamics 365 portal security

Portal Security Concerns

As mentioned, when thinking about security, we have to think about these three things: data, content, and web resources. Also, based on the customer requirements, there are several types of users coming into your portal. They can be anonymous users; customers, partners, or suppliers; power users or senior admin staff; and administrators or technicians. During the planning stage, you must determine the level of access that should be granted to these different categories of users. Consider the following when determining this:

  • Anonymous users should be given the least amount of access, meaning only the public content.

  • The customers, suppliers, or partners should be able to log in to the portal and submit and modify their own data.

  • Power users or senior admin staff might want more sensitive information in the decision-making process or when serving the clients. As an example, granting membership to a club might require additional approval based on the data provided in the application.

  • The most secure level is handled only by the administrators or any other authenticated users or internal staff.

The hierarchy should flow from the least security to most security. That is, the pages should be stacked top to bottom with the least secure pages at the top and the most secured pages at the bottom. As of now, the authentication can be configured in two ways: with local authentication and with external authentication.

  • Local authentication uses the contact records of Dynamics 365 for Customer Engagement for authorization. This is implemented through the common form-based authentication.

  • The ASP.NET Identity API is used for implementing external authentication, which includes user credential management done through a third-party identity provider. This includes Google, Yahoo, and OAuth 2.0–based providers such as Microsoft, Facebook, and Twitter. When configured, the external identity will have the same access as the internal identity.

You can use invitations and trigger confirmation e-mails with both these approaches. Portal administrators have the ability to enable or disable any of these combinations through the Site Settings. As explained, when you configure a portal, by default the contact-based authentication is configured. In the next section, let’s look at the capabilities of the contact-based authentication approach.

Contact-Based Authentication

This is considered to be the simplest form of authentication you will get with Dynamics 365 portals; it uses the contacts of the Dynamics 365 for Customer Engagement organization.

Register a User

Let’s assume a scenario where a contact of the Small Businesses Membership Association (SBMA) wants to register via the portal and is planning to participate in one of the events organized by the association. When you navigate to the portal and click “Sign in,” you will be taken to the login page, which has three tabs: Sign-in, Register, and Redeem invitation. Figure 2-2 shows the Register tab.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig2_HTML.jpg
Figure 2-2

Login page of the portal

Let’s enter some data to register and see what happens. The user will be taken to the Profile page, as shown in Figure 2-3, where they can enter their personal details. On this page, users can update the details and change their e-mail and password. Also, the “Manage external authentication” option lists the configured external authentication provider that the user account is associated with.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig3_HTML.jpg
Figure 2-3

Contact’s Profile page

When the user registers, the user will be created as a contact, as shown in Figure 2-4, and this user can navigate around the portal with limited access to the data and resources.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig4_HTML.jpg
Figure 2-4

Contact record created after user registration

When logged in to the portal, the authenticated user has access to the page called Full Page with Child Links (Figure 2-5).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig5_HTML.jpg
Figure 2-5

Pages accessible to the authenticated user

The authenticated user can click the link and navigate to the page (Figure 2-6).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig6_HTML.jpg
Figure 2-6

Authenticated user accessing web page

But this page is hidden from anonymous visitors. When an anonymous user tries to access the web page, they will be redirected to the login page asking for credentials (Figure 2-7). This is enforced using web page access controls, which we will discuss later in this chapter (in the section “Control Web Page Access for Portals”).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig7_HTML.jpg
Figure 2-7

An anonymous users cannot see this page

When a user with administrative access logs in, they can access anything and even use the web content editor (Figure 2-8).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig8_HTML.jpg
Figure 2-8

System admin login

Now there is a new editor available for system administrators (Figure 2-9). Please note that at the time of writing this book, this editor is in preview mode. You can learn more about the new content editor at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/portal-new-content-editor.

Note

Microsoft has most recently introduced PowerApps Portal, which enables organizations to create low-code portal solutions for their external customers and allows them to interact with common Data Sources. Microsoft has also started merging the capabilities offered by the Dynamics 365 for Customer Engagement portal with PowerApps Portal. For further reading, please visit https://powerapps.microsoft.com/en-us/blog/introducing-powerapps-portals-powerful-low-code-websites-for-external-users/.

../images/483079_1_En_2_Chapter/483079_1_En_2_Fig9_HTML.jpg
Figure 2-9

New portal editor

We will be discussing the content editor later in this book. An internal staff member who has access to the contacts can easily change the password of the contact. On the command ribbon of the Dynamics 365 interface, click the “Change password of the portal contact” option (Figure 2-10).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig10_HTML.jpg
Figure 2-10

Changing the password for a contact

On the right side of the screen, the “Change password for portal contact” pane appears. In this pane, you will have to select the contact for which you want to change the password. As illustrated in Figure 2-11, first select the contact from the lookup and click Next. Finally, change the password and share with the contact via a separate e-mail.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig11_HTML.jpg
Figure 2-11

Selecting a contact from the lookup and changing the password

Please note that the password is visible, and it is always a good practice to advise the contact to change it at the next login. In the next section, you will look at external authentication.

External Authentication

As mentioned at the beginning of this chapter, portal visitors and contacts can also be authenticated via third-party authentication providers. The following are the supported external authentication providers:

  • Microsoft

  • Google

  • Yahoo

  • Facebook

  • Twitter

  • LinkedIn

Note

For the brevity of this book, I will be discussing the configuration of the Microsoft and Google authentication providers. For other provider configuration, please visit https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-oauth2-settings. Also, note that you can specify multiple providers so that the visitors can select the one they most prefer.

The external identity providers that are based on OAuth 2.0 require you to register an application to acquire the client ID and client secret. Most of the time, when registering the application, the redirect URL to the portal must be specified so that the user will be redirected back to the portal. Then, in the portal’s Site Settings, this client ID and the client secret are configured to establish a secure connection between Dynamoics 365 portals an the external identity provider. First, let’s look at how to set up Google as the external identity provider.

Google
  1. 1.
    Navigate to Google Developer Console: https://console.developers.google.com. You will be requested to log in using your Google credentials. You can select an existing project, or you can create a new project, as shown in Figure 2-12.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig12_HTML.jpg
    Figure 2-12

    Creating a new Google API project

     
  2. 2.
    Click New Project to create a new project. You can enter a new project name or leave the default one and click Create (Figure 2-13).
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig13_HTML.jpg
    Figure 2-13

    Creating a new project

     
  3. 3.
    Navigate to the Credentials section and click Create Credentials, as shown in Figure 2-14. From the drop-down options, select OAuth Client ID.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig14_HTML.jpg
    Figure 2-14

    Creating credentials

     
  4. 4.
    Then you will be directed to the form to select the application type. From the options, select Web Application. This will display the form shown in Figure 2-15. You also need to enter the following entries:
    1. a.

      Authorized JavaScript origins: This is the URL of the portal/web page where your request originates.

       
    2. b.

      Authorized redirect URIs: This is the callback URL that will be used to redirect the user once the request validation is successful.

      After entering these values, click Create.
      ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig15_HTML.jpg
      Figure 2-15

      Selecting an application type

       
     
  1. 5.

    Now the credentials are created, and you will be prompted with the client ID and client secret (Figure 2-16).

    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig16_HTML.jpg
    Figure 2-16

    Client ID and client secret

    You need to take note of the client ID. The client secret is not required here.

     
  1. 6.
    Once all this is done, you must update the Site Settings of the portal. Navigate to Portals and then to Site Settings. The following are the entries you should set up. These settings have the format of Authentication/OpenIdConnect /<provider> /<Setting>. The provider will be used as the caption on the login screen.

    • Authentication/OpenIdConnect/Google/Authority: This is the URI to get the authentication token.

    • Authentication/OpenIdConnect/Google/ClientId: This is the client ID generated when you created the credentials, which is registered with the Google API.

    • Authentication/OpenIdConnect/Google/RedirectUri: This should be the same value that you enter when registering the Google API.

     
Figure 2-17 illustrates the values entered in Site Settings.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig17_HTML.jpg
Figure 2-17

Google authentication entries

Now when you navigate to the sign-in page, you can see the Google “Sign-in” button, as illustrated in Figure 2-18.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig18_HTML.jpg
Figure 2-18

Google “Sign-in” button

When the end user clicks the Google button, the user will be directed to the Sign in with Google prompt (Figure 2-19).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig19_HTML.jpg
Figure 2-19

Sign in with Google prompt

After entering an e-mail and clicking the Next button, the user will be directed to the portal page to enter the e-mail address to register, as shown in Figure 2-20.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig20_HTML.jpg
Figure 2-20

Registering with a Google e-mail address

When click the Register button, the user will be directed to the Profile page, where the user can complete the profile (Figure-2-21).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig21_HTML.jpg
Figure 2-21

Profile page

You can see the “E-mail address” field is populated with your Gmail address.

Microsoft
  1. 1.

    Previously this was done through https://account.live.com/developers/applications/index.

    As of May 2019, this will no longer available, and the application registration will be done through Azure Portal. Log in to Azure Portal and navigate to the App Registration section. Navigate to the “Owned applications” tab, as shown in Figure 2-22.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig22_HTML.jpg
    Figure 2-22

    Creating the app registration

     

Note

App registration was replaced in May 2019.

  1. 2.
    Click the +New registration and enter the following fields:
    1. a.

      Name of the application.

       
    2. b.

      “Supported account types” determines what type of accounts have access, and for this example, we will be selecting the third option: “Accounts in any organizational directory and personal Microsoft accounts (e.g., Outlook, Skype, Xbox).”

       
    3. c.

      Finally, specify the redirect URL. The redirect URL is important for most authentication scenarios. As discussed, this URL will be used to return the authentication response.

       
    After filling the form, click Register (Figure 2-23).
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig23_HTML.jpg
    Figure 2-23

    Registering the application

    Once the application is successfully registered, you will be redirected to the screen shown in Figure 2-24.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig24_HTML.jpg
    Figure 2-24

    Registered application overview

    On this form, you can see that the application ID is displayed. When you register the application, you will not get a client secret. The client secret must be generated, and it can be done by going into “Certificate & secrets.”

     
  2. 3.
    Under “Certificate & secrets,” click “Create a new secret,” as shown in Figure 2-25. Specify the name and the expire settings.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig25_HTML.jpg
    Figure 2-25

    Creating a client secret

     
  3. 4.

    The next step is to configure the Site Settings (Figure 2-26). Navigate to the portal’s configuration and then to Site Settings. The following settings are already entered under the Active Site Settings; you only need to populate the values.

    Authentication/OpenAuth/Microsoft/Caption: This is the caption of the button.

    Authentication/OpenAuth/Microsoft/ClientId: This value is from the authentication provider application. You can find the client ID on the Overview page.

    Authentication/OpenAuth/Microsoft/ClientSecret: This value is from the authentication provider application. You need to enter the client secret you’ve generated here.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig26_HTML.jpg
    Figure 2-26

    Microsoft authentication settings

     
  4. 5.
    Navigate to the sign-in page of the portal; you will see the Microsoft button as an external sign-in option (Figure 2-27).
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig27_HTML.jpg
    Figure 2-27

    Sign-in page with Microsoft authentication

     
  5. 6.
    Click the Microsoft button, and it will prompt you to enter your Microsoft ID (Figure 2-28). As usual, enter the e-mail and password.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig28_HTML.jpg
    Figure 2-28

    Microsoft login screen

     
On the next screen (Figure 2-29), you must let the application access your information; click Yes to continue.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig29_HTML.jpg
Figure 2-29

Allowing the application to access your information

As shown in Figure 2-30, you will be asked to register your external account by entering your e-mail.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig30_HTML.jpg
Figure 2-30

Registering your e-mail

Click the Register button, and you will be directed to the profile page, as shown in Figure 2-31.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig31_HTML.jpg
Figure 2-31

Profile page for the externally authenticated user

Similar to this, you can configure the other external authentication providers based on your client requirements. In the next section, you will look at the Azure AD B2C configuration.

Azure AD B2C Provider

Azure Active Directory B2C is an identity management service that enables you to configure and control user authentication with your web, mobile, desktop, or single-page application. The Azure AD B2C allows the users of your application to sign up, sign in, edit profiles, and reset passwords. This authentication mechanism is built on the OpenID and OAuth 2.0 protocols, which use a security token to provide secure access to your application. This book will look at how Azure AD B2C can be used to provide authentication to your Dynamics 365 portals. It is highly recommended that you have some background knowledge about Azure AD B2C before commencing this section. For more details about Azure AD B2C, please visit https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-overview.

Dynamics 365 portals can be configured to use Azure AD B2C to authenticate external users of the system. During the configuration process of Azure AD B2C, several values will be generated, and you should use these values to configure portal authentication. The following are the values that you should note: Application-Name, Application-ID, Policy-Sign in-URL, and Federation-Name.

  • Application-Name represents the portal as a trusted party.

  • Application-ID is linked with the application created in Azure Active Directory B2C.

  • Policy-Sign in-URL is the issuer URL specified in metadata endpoint.

  • Federation-Name is the distinctive name to identify the B2C provider and is used with Site Settings to group configuration settings for this specific provider.

Create an Azure AD B2C Tenant

As the first step, you must create an Azure AD B2C tenant. First sign into the Azure Portal (Figure 2-32).
  1. 1.
    Next, choose “+Create a resource” in the top-left corner of the portal and search and select Active Directory B2C.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig32_HTML.jpg
    Figure 2-32

    Azure Active Directory B2C home page

     
  2. 2.
    Click the Create button. On this screen, enter the relevant details and click Create at the bottom-right corner of the screen (Figure 2-33).
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig33_HTML.jpg
    Figure 2-33

    Creating an Azure AD B2C tenant

     
  3. 3.
    As the next step, click the “Link an existing Azure B2C Tenant to my Azure Subscription” and enter the details, as shown in Figure 2-34.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig34_HTML.jpg
    Figure 2-34

    Linking an existing Azure AD B2C tenant to you Azure subscription

     
  4. 4.
    Before starting to use the tenant, you must make sure that you are using the directory that contains the tenant. Click the subscription page, and the Global Subscription filter will be shown on the right side of the browser window. Switch the directory if required (Figure 2-35).
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig35_HTML.jpg
    Figure 2-35

    Switching the directory

     
  5. 5.
    The next step is to register the application. On the Applications tab, click +Add, as shown in Figure 2-36.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig36_HTML.jpg
    Figure 2-36

    Adding a new application

    On the next screen, enter the name of the application and select Yes for both “Include web app/ web API” and “Allow implicit flow.” Also, set the reply URLs as shown in Figure 2-37.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig37_HTML.jpg
    Figure 2-37

    New application settings

     
  1. 6.
    Now that you have created the application, you must generate the key on the Keys tab (Figure 2-38). Copy the value when generated, because you will not be able to view the value again. But you can remove the existing one and can always generate a new one.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig38_HTML.jpg
    Figure 2-38

    Generating a key

     
  2. 7.
    The next step is to create the sign-up and sign-in policy. This is done through user flows. You can learn more about user flows from the following link: https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-policies#create-a-sign-up-or-sign-in-policy. Select User Flows from the left pane and click +Create New in the toolbar. On the next screen (Figure 2-39), you will see three tabs: Recommended, Preview, and All. You should start by selecting the user flow type. For this example, we will be selecting recommended flows, which can be used for most applications.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig39_HTML.jpg
    Figure 2-39

    Selecting a user flow type

     
  3. 8.

    On the Create screen, there are a few mandatory fields that you should fill in. First, you should enter the name, which is a unique string to identify the user flow requests to Azure AD B2C (Figure 2-40).

    Note Since this is a lengthy form, each section will be explained separately.

    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig40_HTML.jpg
    Figure 2-40

    User flow name

     
  4. 9.
    As shown in Figure 2-41, you can define the identity providers, and you should select at least one here. So we will be selecting the default one for this example. Also, you could define multifactor authentication here, but let’s leave it disabled for this example.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig41_HTML.jpg
    Figure 2-41

    Defining identity providers

     
  5. 10.
    The next step is to define the user attributes and claims that are collected during sign-up. By default on this screen, only a few fields are defined. Click the “Show more” link to add more fields. After selecting the fields required, then click the Ok button (Figure 2-42).
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig42_HTML.jpg
    Figure 2-42

    User attributes and claims

     
  6. 11.
    Finally, click the Create button at the bottom of the screen to complete the process, and the new user flow will be created. Similarly, create the user flow for Profile Editing and Password Reset. As shown in Figure 2-43, all flows you have created will be listed.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig43_HTML.jpg
    Figure 2-43

    List of user flows created

     
  7. 12.
    After creating the user flows, you must set the following settings for each flow you have created. Open the Properties tab of the flow and under “Token compatibility settings,” select the URL with the /tfp/, as shown in Figure 2-44. This will be used to identify the claims that issued the token.
    ../images/483079_1_En_2_Chapter/483079_1_En_2_Fig44_HTML.jpg
    Figure 2-44

    User flow properties

     

Perform this action for the other flows you have created. There are other properties on this form, and you can configure them as per the requirements.

Portal Configuration

Now that you have configured Azure AD B2C, the next step is to configure the portal to federate with Azure AD B2C using the Open ID Connect protocol.
  1. 1.

    Sign into the Dynamics 365 portal app and open Site Settings. Create the following entries:

     

Name

Value

Authenticationn/OpenIdConnect/B2C/Authority

<The issuer URL>

Authentication/OpenIdConnect/B2C/ClientId

2f9237da-553f-41b0-a79f-374e83ba8b28

Authentication/OpenIdConnect/B2C/RedirectUri

https://sbmamember.microsoftcrmportals.com/signin-b2

  1. 2.

    To support the federated sign-out, create the following entry in Site Settings:

     

Name

Value

Authentication/OpenIdConnection/B2C/ExternalLogoutEnabled

true

  1. 3.

    Create the following entry to hard-code the portal to a single identity provider:

     

Name

Value

Authentication/OpenIdConnection/B2C/LoginButtonAuthenticationType

<Policy sign in URL>

  1. 4.

    Configure the password reset and create the following entries:

     

Name

Value

Authentication/OpenIdConnect/B2C/PasswordResetPolicyId

<ID of password reset policy>

Authentication/OpenIdConnect/B2C/ValidIssuers

<A comma-separated list of issuers that includes the policy sign-in URL and the issuer>

Authentication/OpenIdConnect/B2C/DefaultPolicyId

<ID of the sign-in/sign-up policy>

  1. 5.

    To support the claims mapping, enter the following entries:

     
  1. 6.

    Then enter the caption of the button:

     

Name

Value

Authentication/OpenIdConnect/B2C/Caption

Azure AD B2C

For more settings such as related site settings, related content snippets, etc., please visit https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/azure-ad-b2c#portal-configuration.

Figure 2-45 illustrates the list of values entered into Site Settings.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig45_HTML.jpg
Figure 2-45

Azure B2C Site Settings

Let’s do a quick test to see whether it navigates to the Azure AD B2C login page. As shown in Figure 2-46, click the Azure AD B2C button.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig46_HTML.jpg
Figure 2-46

Sign-in page, Azure AD B2C

If you have set up the configuration correctly, then you will be directed to the default login screen, as shown in Figure 2-47.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig47_HTML.jpg
Figure 2-47

Azure AD B2C login screen

User Authorization

No matter what authentication technique is used in your portal, once a user is authenticated, you should authorize the user. This means you are giving authorization to perform certain tasks on the portal. First, let’s look at web roles, which are the cornerstone for authorizing the contacts.

Web Roles

After authenticating the contacts, every contact must be granted a web role. By default, when you configure the portal, you will get three web roles that are considered the most commonly used. Navigate to Web Roles under the Security section in the left navigation pane (Figure 2-48).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig48_HTML.jpg
Figure 2-48

Active web roles

As shown in Figure 2-43, there are three web roles that were created: Administrator, Anonymous Users, and Authenticated Users (these roles were briefly described at the beginning of this chapter). To dig deep into these roles, let’s open the Anonymous Users and Authenticated Users roles (Figure 2-49).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig49_HTML.jpg
Figure 2-49

Anonymous Users and Authenticated Users web roles

Let’s look at the properties in the roles illustrated in Figure 2-49.
  1. 1.

    Name: The value of this property is a descriptive name that will be used to identify the web role.

     
  2. 2.

    Website: This is the associated web site of the web role.

     
  3. 3.

    Description: This is an optional field that can be filled only if you want to add more detail about the role.

     
  4. 4.

    Authenticated User Role: This is a Boolean value, and if set to true, then the role will be the default for authenticated users. There can be only one web role with this setting set to true. This will be the default web role for authenticated users who have not been assigned a web role.

     
  5. 5.

    Anonymous User Role: This also a Boolean value, and if set to true, then the role will be the default for unauthenticated users. There can be only one web role with this setting set to true, and it will be the default web role for unauthenticated users. This will solely adhere to the entity permissions.

     

The administrator permission is the superuser for the portal, and by default, the role cannot do much. Therefore, you should edit this role to make it a proper Administrator role. In addition to these, you can create other web roles as per your requirements. The next level of web roles is the entity permissions, which will determine the record-level access of the authenticated users.

Entity Permissions

The entity permissions are used to grant record-level permissions to authenticated users. Once the entity permissions are created, they can be associated with the web roles. You should keep in mind that an authenticated portal user can have multiple roles, and a given web role will have multiple entity permissions. As a best practice, when you design the portal, you should consider determining the web roles and entity permissions. You can create the entity permissions under the entity permissions and add them to the web roles. For instance, the example of this book uses event management. Let’s assume we want to provide entity permission to administrators for the Event entity.

Navigate to Entity Permissions and click New. Fill in the required information and select the entity from the drop-down list on the right side of the screen (Figure 2-50).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig50_HTML.jpg
Figure 2-50

Event entity permissions

The other important thing when creating the entity permissions is the scope, which determines whether the user has access to all the records. For instance, as per this example, if the global scope is defined, then the web role that this permission is assigned to will have access to all the records in the system.

In our example, we will be giving full access to the event records for those users who have the Event Administrator role. This Event Administrator role will be associated with the Event entity admin permission that was created earlier. The next step is to create the child permissions to related record. The requirement is that the Event Administrators should have access to all the events, event registrations, payments, and other event planning details.

Navigate to the entity permission created, scroll down to the subgrid that lists the child permissions, and click the +Add New Entity Permission button on the command bar (Figure 2-51).
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig51_HTML.jpg
Figure 2-51

Child entity permission settings

Enter all the required information and select Parent as the scope; you will notice a new section appears so you can enter the relationship details. This implies that the event administrator will have full control over the event registration of a given event.

Important

For these permissions to work, you must enable entity permissions on the entity lists and entity forms. See Figure 2-52 and Figure 2-53. Furthermore, the child or the related entity must have a subgrid on the parent form. That is, the event form should list all the related event registrations that the user can click and open. In addition, you should also configure the Event Registration entity forms with create and edit permissions. In the next chapter, this book will demonstrate the actual usage of this permission when configuring and editing lists and forms.

../images/483079_1_En_2_Chapter/483079_1_En_2_Fig52_HTML.jpg
Figure 2-52

Entity form enabled for entity permissions

../images/483079_1_En_2_Chapter/483079_1_En_2_Fig53_HTML.jpg
Figure 2-53

Entity list enabled for entity permissions

Control Web Page Access for Portals

The web page access rules are defined to govern the actions that a web role can perform and which pages are visible to the web role. By default, there will be three rules defined, and you can define your own based on the security requirements of your organization or client. Figure 2-54 illustrates the high-level view of how web page access control rules are applied.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig54_HTML.jpg
Figure 2-54

Web page access control rules

When you navigate to Security and then “Web page access control rules,” you can see the list of access control rules in the current configuration. Also, every web page has an Access Control Rule tab that lists all the access control rules associated with the current page. Figure 2-55 illustrates the list of properties of the access control rules.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig55_HTML.jpg
Figure 2-55

Web page access rules

There are few important properties you should understand on this form.

  • Web Page: This is the page the rules will apply to, and it will be applied to all the child pages of this page. So, you must be extra careful because if you select the home page, the rule will be applied to all the pages within the portal.

  • Right: There are two options available: Grant Change and Restrict Read.

    Grant Change enables the user in the web role linked with the rule to publish content changes to both the current page and its child pages. Grant Change will take precedence over a restricted read. For instance, within a given event details page, the event organizer should be able to publish updates, but they should not have the full access rights to other parts of the site. You should set the Grant Change right on the event page and assign the associating web role to the relevant contact/user, making them the publisher of this event. If you want to allow front-end editing, then you should always look into setting up Grant Change rules.

    Restrict Read will limit specific users from viewing a page and its child pages. This is a restrictive rule that limits a set of users. For instance, you might want the event organizers to access the event section of the portal only.

  • Scope: This property will have two option. “All content” means the security validations will be enforced on all the child content. “Exclude direct child web files” will ignore child web content directly related to the current web page from the security validations. The default value is “All content.”

    How this works is bit tricky. Let’s assume a scenario where you have four web pages: wp1, wp2, wp3, and wp4. If you want to give access to wp1 and wp2 to the anonymous user, restrict wp3 and wp4 using an authenticated web role for the access control rule. The logged-in/authenticated users can see wp3 and wp4, and the anonymous users can see wp1 and wp2 but not wp3 and wp4. If the anonymous user clicks the wp3 or wp4 link, they will be directed to the sign-in page.

Create Web Site Access Permissions

These permissions will permit the users to edit the elements of the portal other than the web pages. The settings will determine which components will be managed in the portal. By default, there are two such rules created. See Figure 2-56.
../images/483079_1_En_2_Chapter/483079_1_En_2_Fig56_HTML.jpg
Figure 2-56

Web site access permissions

Under the Permissions section, the following settings are available:

  • Manage Content Snippets allows modifications to the snippet control.

  • Manage Site Markers permits modifications to the hyperlinks that use the site markers.

  • Manage Weblink Sets permits adding and removing links from the web link sets.

  • Preview Unpublished Entities allows users to view the portal-enabled entities in draft mode.

As shown in Figure 2-56, you can specify the web roles for this rule on the Web Roles tab.

Summary

With that, I have covered most of the important security aspects of portals including both authentication and authorization. In the next chapter, I will demonstrate how to display content on the web pages.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.96.5