Please see this document if upgrading from Adxstudio Portals 7.0.0006 or earlier.
This documentation applies to Adxstudio Portals 7.0.0007 and later versions.

The latest portal authentication experience allows portal users to sign in with their choice of a local Contact Membership Provider based account or a federated account based on OpenAuth and ACS. Both local and federated account registration can take advantage of the invitation code sign up model as well as the email confirmation workflow. In addition, portal administrators may choose to enable or disable any combination of authentication options through portal site settings.

Local Authentication

Local authentication is the common forms-based authentication that is backed by the Contact Membership Provider. Like any other membership provider, the Contact Membership Provider stores account credentials in a local data store and, in this case, takes the form of contact records of a Dynamics CRM organization. Changing passwords and managing other account details is the responsibility of the local portal. For developers, a membership provider means that the suite of ASP.Net web controls is available for building custom authentication experiences.

Federated Authentication

Federated authentication is provided by both the Microsoft DotNetOpenAuth helpers for ASP.NET Membership as well as the Windows Azure Access Control Service (ACS). 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 a federated identity to register with the portal. Once registered, a federated identity has access to the same features as a local account.

Account Sign Up (Registration)

Portal administrators have several options for controlling account sign up behavior. Open registration is the least restrictive sign up configuration where the portal allows a user account to be registered by simply providing a user identity. Alternative configurations may require users to provide an invitation code or valid email address to register with the portal. Regardless of the registration configuration, both local and federated accounts participate equally in the registration workflow. That is, users have the option to choose which type of account they wish to register.

Open Registration

During sign up, the user has the option of creating a local account (providing a username and password) or selecting a federated identity from a list of identity providers. If a federated identity is selected, the user is required to sign in through the chosen identity provider to prove that they own the federated account. In either case, the user is immediately registered and authenticated with the portal. A new contact record is created in the CRM organization upon sign up.

With open registration enabled, users are not required to provide an invitation code to complete the sign up process. Open registration is enabled by setting all of the following site settings to false:

  • Authentication/Registration/RequiresInvitation
  • Authentication/Registration/RequiresConfirmation

Email Confirmation

When the email confirmation feature is enabled, a user attempting to sign up with the portal is first required to submit a valid email address. A new contact record is created containing the submitted email address as well as an auto-generated invitation code. Next, an email message is sent to the address with the invitation code in the body of the message. This is achieved by executing the CRM process (workflow) named ADX Sign Up Email (the email message contents can be edited by modifying this process). At this point, the standard invitation code registration process takes over. By redeeming the invitation code, the user proves ownership of the email account in the process of registering with the portal.

Even though an invitation code is involved, the code is auto-generated to allow public registration. Consequently, email confirmation can be considered a variation of open registration.

Enabling (requiring) invitation code will disable email confirmation regardless of whether email confirmation is enabled or disabled. In other words, in order to enable email confirmation, invitation must be disabled.

User Registration Settings and Workflows

The user sign up process involves the following forms (steps) used in various workflows depending on several (boolean) registration settings.

Registration Settings

Name Site Setting Name Default Value
Requires Invitation Authentication/Registration/RequiresInvitation false
Requires Email confirmation Authentication/Registration/RequiresConfirmation false

Registration Forms

Name Form
Open registration sign up
Submit invitation code
Redeem invitation code
Submit email address

Registration Workflows

Requires Invitation Requires Email Confirmation Form Workflow
    Not applicable. Invitation overrides email confirmation. Behaves as though email confirmation is disabled.
  1. Submit invitation code
  2. Redeem invitation code
  1. Submit email address (retrieve invitation from inbox). Alternative: go to Submit invitation code without submitting an email
  2. Submit invitation code
  3. Redeem invitation code
Note: This is a variant of open registration where registration is available to the public as long as a valid email is provided.
  1. Open registration sign up. Alternative: Create User OR Go to Submit invitation code
  2. Alternate: Go to Sign in form. Sign in with a federated identity provider (not applicable to local accounts). Automatically generate a contact for the federated identity.