Dynamics 365 Portal Authentication - Using SAML 2.0 Provider

Some of the SAML 2.0 Identity providers are :

• Azure Active Directory
• Active Directory Federation Services ( ADFS)
• Shibboleth Identity Provider 3

With SAML single sign-on, Azure AD authenticates to the application by using the user's Azure AD account. Azure AD communicates the sign-on information to the application through a connection protocol. With SAML-based single sign-on, you can map users to specific application roles based on rules you define in your SAML claims.

Choose SAML-based single sign-on when the application supports it.

SAML-based single sign-on is supported for applications that use any of these protocols:

• SAML 2.0
• WS-Federation

Configuring for portal 

1. Under the App Registration menu of the  Azure Active directory, select New Application.

2. Specify a custom name for the application, choose the appropriate supported account type. 

4. At this point, a new application is created. Go to the Authentication section in the menu.

 Under Redirect URI specify the URL of the portal http://portal.contoso.com/signin-azure-ad. and the logout URL if required.

A standard Azure AD configuration only uses the following settings (with example values): Authentication/SAML2/AzureAD/MetadataAddress - https://login.microsoftonline.com/01234567-89ab-cdef-0123-456789abcdef/federationmetadata/2007-06/federationmetadata.xml

Authentication/SAML2/AzureAD/AuthenticationType - https://sts.windows.net/01234567-89ab-cdef-0123-456789abcdef/

Use the value of theentityID attribute in the root element of the federation metadata (open theMetadataAddress URL in a browser that is the value of the above site setting)

Authentication/SAML2/AzureAD/ServiceProviderRealm - https://portal.myexample.com/

Authentication/SAML2/AzureAD/AssertionConsumerServiceUrl - https://portal.myexample.com/signin-azure-ad |

Dynamics 365 Portal Authentication - Using OAuth2.0 Providers

The supported OAuth2.0  providers are:

• Microsoft Account
• Twitter
• Facebook
• Google
• LinkedIn
• Yahoo

They all involve registering the portal application with a third-party service to obtain a client ID and client secret pair. A redirect URL needs to be specified that allows the identity provider to send users back to the portal.

How to configure for Google

Google OAuth2 API Credentials Instructions

1. Open Google Developers Console
2. Create an API project or open an existing project
3. Go toAPIs & auth >APIs, and under Social APIs, selectGoogle+ API, and then selectEnable API
4. Go toAPIs & auth >Consent screen.
   • Specify anEmail address.
   • Specify a customProduct name.
   • SelectSave.
5. Go toAPIs & auth >Credentials and create a new client ID.
• Application Type:Web application
• Authorized JavaScript Origins: http://portal.myexample.com
• Authorized Redirect URIs: http://portal.myexample.com/signin-google
• Select Create Client ID.

How to configure for Facebook

1. Open Facebook Developers App Dashboard
2. Select Add a New App.
3. Select Website.
4. Select Skip and Create App ID.
   • Specify a Display Name.
   • Choose a Category.
   • Select Create App ID.
5. While on the dashboard for the new app, go to Settings >Basic (tab) and add the following details:
   • App Domains (optional): portal.myexample.com
   • Contact Email: <email address of your choice>
   • Select Add Platform, and then select Website.
   • Site URL: http://portal.myexample.com/ or http://portal.myexample.com/signin-facebook
6. Select Save Changes.
7. Go to Status & Review > Status tab.
8. Select Yes when prompted to make the app and all its features available to the general public. You must have filled in the valid data in Step 5 above to enable this setting.

How to configure for Microsoft

1. Open Microsoft account Developer Center
2. Select Create application and specify an Application name.
3. Select I accept to accept Terms and Conditions.
4. Go to Settings >API settings, and then set the redirect URL as http://portal.myexample.com/signin-microsoft

How to configure for Twitter

1. Open Twitter Application Management.
2. Select Create New App.
   • Specify a Name and Description for your app.
   • Set the Website URL as http://portal.myexample.com.
   • Set the Callback URL as http://portal.myexample.com or http://portal.myexample.com/signin-twitter.
3. Select Create your Twitter application.

How to configure for LinkedIn

1. Open LinkedIn Developer Network.
2. Select Add New Application.
   • Specify an Application Name, Description, and so on.
   • Set Website URL as http://portal.myexample.com.
   • Set OAuth User Agreement/Default Scope: r_basicprofie and r_emailaddress
   • Set OAuth 2.0 Redirect url: http://portal.myexample.com/signin-linkedin.
3. Select Add Application.

How to configure for Yahoo

1. Open Yahoo! Developer Network.
2. Select Create an App.
   • Specify an Application Name.
   • Application Type: Web Application.
   • Callback Domain: portal.myexample.com
3. Select Create App.

Following site settings need to be configured on the portal (replace [provider] with google,facebook,twitter,linkedin,Microsoft,yahoo depending on which one is getting used) :

Site Setting Name	Description
Authentication/Registration/ExternalLoginEnabled	Enables or disables external account sign-in and registration. Default: true
Authentication/OpenAuth/[provider]/ClientId	Required. The client ID value from the provider application. It may also be referred to as an App ID or Consumer Key. The following setting names are allowed for backwards compatibility: Authentication/OpenAuth/Twitter/ConsumerKey Authentication/OpenAuth/Facebook/AppId Authentication/OpenAuth/LinkedIn/ConsumerKey
Authentication/OpenAuth/[provider]/ClientSecret	Required. The client secret value from the provider application. It may also be referred to as an App Secret or Consumer Secret. The following setting names are allowed for backwards compatibility: Authentication/OpenAuth/Twitter/ConsumerSecret Authentication/OpenAuth/Facebook/AppSecret Authentication/OpenAuth/LinkedIn/ConsumerSecret
Authentication/OpenAuth/[provider]/AuthenticationType	The OWIN authentication middleware type. Example: yahoo. authenticationoptions.authenticationtype.
Authentication/OpenAuth/[provider]/Scope	A comma separated list of permissions to request. microsoftaccountauthenticationoptions.scope.
Authentication/OpenAuth/[provider]/Caption	The text that the user can display on a sign in user interface. microsoftaccountauthenticationoptions.caption.
Authentication/OpenAuth/[provider]/BackchannelTimeout	Timeout value in milliseconds for back channel communications. microsoftaccountauthenticationoptions.backchanneltimeout.
Authentication/OpenAuth/[provider]/CallbackPath	The request path within the application's base path where the user-agent will be returned. microsoftaccountauthenticationoptions.callbackpath.
Authentication/OpenAuth/[provider]/SignInAsAuthenticationType	The name of another authentication middleware which will be responsible for actually issuing auserClaimsIdentity. microsoftaccountauthenticationoptions.signinasauthenticationtype.
Authentication/OpenAuth/[provider]/AuthenticationMode	The OWIN authentication middleware mode. security.authenticationoptions.authenticationmode. Source of this article is https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-oauth2-settings s

Dynamics 365 Portal Authentication Basics

Dynamics 365 Portal authentication is built on the ASP.NET Identity API which in turn is built on the OWIN framework.

1. Local Authentication

It is the common forms-based authentication which uses the contact records of a Dynamics 365 to store the authentication details( password as hashed text, username etc.) It is going to be deprecated soon. 

2. External Authentication

It uses the ASP.NET Identity API to integrate with the external ID providers. For example. Open ID based providers such as Azure AD and Google, OAuth 2.0 based providers such as Twitter, Facebook, Yahoo, Google and Microsoft, SAML 2.0 based providers.

When using external authentication, the user is required to sign in through the chosen identity provider to prove that they own the external account. During sign-up, a new contact record is created in Dynamics365. 

For portal authentication to work properly, ensure that following solutions exist in the environment"

1. MicrosoftIdentity
2. MicrosoftIdentityWorkflows
3. Microsoft IdentitySystemWorkflows
   Users who have an external account can choose to create a local account by applying a username and password. Users who started with a local account can choose to associate multiple external identities to their account. 

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/set-authentication-identity has most of the site settings which needs to be configured for either local or external authentication.