Dynamics 365 Portals provide multiple authentication mechanisms and features which are very easy to configure. Having said that, rather than allow all modes [which may ultimately result in clutter and confusion] answers to a quick survey of the below questions should be collated when finalizing them.
- Who are the Potential portal users – Internal employees and Partners who are available as dynamics contacts or prospects and customers who are external?
- Which mechanism would make it easier for them to login?
- Do you have the required manpower and systems to manage any requests/ issues which may be reported?
- What is the information/ collaboration expected on the Portal?
While authentication is the gateway for a user to access the portal, the below 2 configurations are equally important to be set up for user access.
Basic set up for a Portal User
- Contact set up: In a portal application, an authenticated portal user is associated with either a Dynamics 365 Contact or System User. The default portals configuration is contact-based. The contact can be created
- Web Role: Portal users must be assigned to a web role to gain permissions beyond unauthenticated users.
Portal users can sign in ether with authentication provided by Dynamics 365 contact membership provider or with an external account based on ASP.NET Identity.
Local authentication: Local authentication is the common forms-based authentication uses the contact records of a Dynamics 365 for Customer Engagement organization for authentication.
External authentication: External authentication is provided by the ASP.NET Identity API. In this case, account credentials and password management are handled by a third-party identity provider. This includes OpenID based providers such as Yahoo! and Google and OAuth 2.0 based providers such as Twitter, Facebook, and Microsoft. Users sign up to the portal by selecting an external identity to register with the portal. After it is registered, an external identity has access to the same features as a local account.
- Windows Authentication
- Windows Live ID Web Authentication
- Form Authentication
- External (social provider) user sign-in through third-party identity providers
- Open registration
The Portal login screens
Sign in by using a local identity or external identity
Sign up by using a local identity or external identity
Redeem an invitation code manually
- Email address confirmation
- Authenticated users manage their user accounts through the Security navigation bar of the profile page. The profile page is also where the user is reminded to confirm their email address by requesting a confirmation email to be sent to their email account.
- Password recovery and Password reset
- Returning visitors who require a password reset (and have previously specified an email address on their user profile) can request a password reset token to be sent to their email account
- Redeem invitation
- Both local and external account registration can use invitation codes for sign up, as well as the email confirmation workflow. These invitations can be generated and sent out from Dynamics by permission users by email
- Redeeming an invitation code allows a registering visitor to be associated with an existing contact record that was prepared in advance specifically for that visitor.
- With open registration enabled, however, users are not required to provide an invitation code to complete the sign-up process.
- Two-factor authentication with email
- The two-factor authentication feature increases user account security by requiring proof of ownership of a confirmed email in addition to the standard local or external account sign-in.
- A user trying to sign in to an account that has two-factor authentication enabled is sent a security code to the confirmed email associated with their account. The security code must be submitted to complete the sign-in process
- User Lockout
- When a certain number of failed password attempts are detected in a short period of time, the user account is locked for a period of time. The user can try again after the lockout period elapses
Meanwhile, another interesting related information about the portal which supersedes authentication is that while the Dynamics 365 for Customer Engagement Portal is public when provisioned and accessible by anyone from any computer, now you can restrict access to your portal from a list of IP addresses.
For example, a government organization might want to surface their content only within their corporate network. A commercial organization might want to display the portal only when it is published and not while it is in development to avoid any data leak.
When a request to the portal is generated from any user, their IP address is evaluated against the allow list. If the IP address is not on the list, the portal displays a web page with an HTTP 403 status code!