My First PCF Control: AddressFinder Australian Addresses

First of all, credit to Sankal Bansal on his New Zealand Version of the similar control with the same provider.

I was recently working on a specific task to implement a new Address Autocomplete/Validation solution. So, the selected validation/provider was AddressFinder. This API provider provides quite extensive information that the typical Australian addresses need (GNAF ID, DPID, Geolocation, and some more IDs provided as the metadata).

Traditionally, we create an HTML web resource that interacts with the main page script. But then the roadmap ahead is going towards building PCF controls. So, I decided to give it a go on building this PCF control.

To begin my journey, I was looking at https://pcf.gallery/ and found some good examples of address autocomplete with Azure Maps & Google Maps. I learned the concept from those examples, then I found Sankal’s solution that is almost the same as what I would like to achieve. However, his solution is based on New Zealand’s dataset (metadata and mapping are different) and doesn’t map the full address to a field.

So, I created a specific Australian solution for this PCF. You can find the detail at my github repository: https://github.com/andz88/PCF.AddressFinderAU

The woikaround to get the mapping is to follow this post: https://www.magnetismsolutions.com/blog/jaredjohnson/2019/07/04/binding-to-address-fields-in-a-pcf-control, as this is a known issue with the PCF: https://powerusers.microsoft.com/t5/PowerApps-Ideas/Enable-binding-to-OOB-Address-Fields/idi-p/302387

A quick demo here:

Advertisements

Dynamics 365 Portal – Authentication Deep Dive (Part 4) – Tips & Tricks

Finally, after quite hectic months with all big events are happening in Melbourne, Australia & Globally (Dynamics 365 Saturday, UG Summit and Global Hackathon), I’m going to finalise this series of authentication with Dynamics 365 Portal or should we call it PowerApps Portal now 😉

So, without further ado, here are some tips & tricks in authentication implementation for Dynamics 365 portal:

  1. Set Login Session Timeout

As part of the security policy sometimes we need to set the login session timeout. When I was trying to configure this, usually the Identity Provider will have the configuration of the token lifetime.

So, my first thought was to use the Open ID Connect settings to set the cookie timeout: “Authentication/OpenIdConnect/[provider]/UseTokenLifetime

Well, after some testing, that doesn’t change the timeout. So, to properly change the session timeout apparently, I need to set the following configuration:

Authentication/ApplicationCookie/ExpireTimeSpan

  1. Use default Login Provider

When we configure the external login, sometimes it is a specific direction, to only allow a specific login method for the portal audience. To achieve this, you just need to set the following configuration:
Authentication/Registration/LoginButtonAuthenticationType

Set the value as the same value of the ‘Authority’ of the Authentication Provider URL is:

e.g: if your “Authentication/OpenIdConnect/[provider]/Authority” is “https://login.somewhere.com” put the same value on this setting. This will “force” the login process using the specified provider.

  1. Claim Mapping – Resolve basic contact mapping

When we configured the external Authentication Provider, once we are able to login, usually it will prompt us with the email, then creating new contact record if the record doesn’t exist, or it will complain about the duplicate contact exist and stopped the process, which sometimes frustrating and causing orphaned records…

So, to make it a more seamless experience:

  • Set the “Authentication/OpenIdConnect/[provider]/RegistrationEnabled” to true
  • Set the “Authentication/OpenIdConnect/Auth0/RegistrationClaimsMapping” to reflect the mapping. Commonly we would like to set the First Name, Last Name and Email Address: “firstname=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname,lastname=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname,emailaddress1=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email”

More detail of the claim mapping:

https://docs.microsoft.com/en-us/dynamics365/portals/azure-ad-b2c#claims-mapping

And the options on what we can use from the identity provider:

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

  1. Force Login when accessing pages other than the Home page

In my recent scenario, there is a requirement to make the other web pages not available for non-authenticated users. I can apply the “Authentication Required” on each page on my site. However, this is not an efficient process. In particular around the maintainability of the portal. So to achieve this in an efficient way:

  • Navigate to Web Page -> Home
  • Navigate to the Access Control Rules section
  • Create a new Rule as follows:

Web Access Control.png

Make sure you select to the scope to Exclude direct child web files, otherwise the portal scripts and css will be blocked as well.

  • Add the “Authenticated User” under the Web Role:

Auth Users.png

That’s all the tips & tricks related to the Dynamics 365 Portal authentication. I hope this helps!

Dynamics 365 Portal – Authentication Deep Dive (Part 3) – Using the Third Party Auth Providers

In the previous post, we have discussed how to configure Azure AD B2C using the Open ID Connect method. One of the challenges that I had in my past experience is that the client has a strict requirement of data residency, due to the sensitivity of their business. Therefore, they are considering some 3rd party options that have their solution deployed in Australian data centre. Some of the options that we have explored are Auth0 and Okta.

The same principle of configuring Open ID Connect authentication, these 3 site settings records need to be created & configured:

  • Authentication/OpenIdConnect/[provider]/Authority
  • Authentication/OpenIdConnect/[provider]/ClientId
  • Authentication/OpenIdConnect/[provider]/RedirectUri

Note: The key part of configuring authentication always be getting familiar with the product and how to find the right equivalent information 😊

Example of 3rd party External Identity Provider: Auth0

First of all, we need to make the “Application” as the container of our configuration in Auth0 management portal.

Auth0-Create-App.png

Select the Regular Web App option (this will have pre-configured settings for the auth token required for the majority of web apps).

Auth0-Create-App2.png

Register the Allowed Origin and Callback URL(s) of our portal site. Mine is like below:

Auth0-Create-Config1.png

Take note of the client ID to be used for the portal configuration:

client-id.png

Expand the Advanced settings, take note the OAuth Authorization URL, this will be the value of “Authentication/OpenIdConnect/[provider]/Authority”

Auth0-Authorize.png

Configure the site settings to have the following items:

Auth0-site-settings.png

Quick Demo:

Auth0-Demo.gif

Example of 3rd party External Identity Provider: Okta

Similarly, when configuring Okta, need to set up the application as the container of our web app authentication configurations.

create-app-okta.png

When creating the application, select the Web application

create-app-okta2.png

Configure the base URL, login redirect URL(s) & the Grant Type. I choose the below option (mimicking the Auth0/Azure AD B2C settings). Also, take note of the client ID.

create-app-okta3.png

Okta_Client_ID.png

To find the “Authentication/OpenIdConnect/[provider]/Authority” value, navigate to the API section and take note of the issuer URI

Okta-auth-server.png

And add the Portal Base URL as the allowed/trusted origin

Okta-auth-server-allowed.png

Then finally set up the site settings as below for Okta Auth:

Okta-site-settings.png

Okta Auth Demo

Okta-Demo.gif

Conclusion

I hope the flexibility of the Authentication framework that the Dynamics 365 Portal offers would help you to be able to leverage your existing IDP/Auth provider to connect to Dynamics 365 Portal easily.

In the next post, I will discuss some tips & tricks to get a more seamless end-user experience authenticating to the portal.

Hope this helps!

Dynamics 365 Portal – Authentication Deep Dive (Part 2) – Using the Microsoft Azure AD

The second part of the series of the blog post is to leverage the Microsoft Azure AD capability to deliver the authentication capability for the Dynamics 365 Portal.

There are 2 parts of the Azure AD that we can use depending on the audience:

  1. Internal-facing Portal: Azure AD
  2. External-facing Portal: Azure AD B2C

Now, let’s walk through the detail on each part.

Azure AD Authentication

The Azure AD authentication use case is predominantly for internal users such as employee or contractors accessing an internal company’s portal, such as employee self-service portal.

This feature is enabled by default for Dynamics 365 Portal with this specific Site Setting to look for:

Authentication/Registration/AzureADLoginEnabled

This will provide seamless authentication for all internal users.

How about guest users, such as contractors or partner? Azure AD provides the ability to invite Guest Users via the Azure AD B2B.

Azure AD B2B use case would be for the Partner Portal functionality.

To enable the guest user access, we first need to have the user added in Azure AD as “Guest User”

Guest User.png

In this example, I’m going to add my work account (@barhead.com) to my personal instance (@andz88.com). Once invited, I’ll receive the invitation, click on the Get Started to “redeem”/confirm the invitation. You’ll notice that you don’t have access to any application, but that is fine.

Invitation.png

Once confirmed, I now can login to the portal by clicking on the Azure AD login method using my work (external) account.

Note: If the Azure AD is configured using Federated auth with AD FS, the Portal Azure AD auth also will use AD FS.

Demo:

AzureAD B2B.gif

External facing portal with Azure AD B2C

Azure AD B2C is the option for external users, typically for the public facing portal, such as customer self-service, community portal or partner portal.

Note: at the time of writing this article, Azure AD B2C deployment does not include some regions like Australia: https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-tenant-type

The good news for Australian-based users, Dynamics 365 Portal Authentication is only using Azure AD B2C for the user object ID and securely storing the login credential, PII and other profile information is stored in Dynamics 365, which is hosted in Australian Data Centre.

To implement Azure AD B2C authentication, I would recommend using the Open ID Connect authentication method. This is the commonly used authentication method that is available from most of modern ID/Authentication providers. So, to begin with, there are 3 main Site Settings that you will need to pay attention to enable any kind of Open ID Connect authentication:

  • Authentication/OpenIdConnect/[provider]/Authority
  • Authentication/OpenIdConnect/[provider]/ClientId
  • Authentication/OpenIdConnect/[provider]/RedirectUri

The [provider] part of the settings should be replaced by the name of the authentication method/provider that you would like to name (this also become the display name of the authentication button at the sign in page).

From the Azure AD B2C perspective, once you’ve created the Azure AD B2C deployment, you will need to add Dynamics Portal application to the list:

Application Reg.png

Create the application, make sure that the “Allow Implicit Flow” set to Yes. Reply URL should be in the format “[portal domain]/signin-[Federation-Name]” (Ref: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/azure-ad-b2c)

AppSetup.png

Once the Dynamics Portal application added to AAD B2C application, you’ll need the ensure to set up the user flows/policies:

Sign-in Policy 1.png

At least configure the Sign in and Sign Up & Password ResetSign-in Policy 2.png

In particular, on the Signup and sign in policy, set the bare minimum information for the claim, such as email address, first name and last name and keep the rest to be managed in Dynamics 365 (unless you would leverage the full capability of Azure AD B2C to manage the profile). The tips & tricks on configuring the claim I’ll discuss in the next posts.

Once configured you will need to grab the 3 most basic information: Authority, ClientId and Redirect Url.

To find the value for the “Authority”, open the Sign up and sign in policy that you’ve created and click on Run user flow:

RunUserFlow.png

It will open a panel, click this well-known/openid-configuration link to see the JSON metadata:

AAD Authority.png

And grab the value from “issuer” to be value for the Authority.

Issuer.png

The value of ClientId is the GUID of the application that you created in the previous step:

ClientId.png

And RedirectUri is the from the Reply URL that we set in that application

ReplyUrl.png

Once configured, you will be able to sign in using users that have been registered in the Azure AD B2C:

Azure AD B2C Demo.gif

Hope this helps. In the next post, I’ll discuss using some 3rd party identity providers as the alternative of Azure AD B2C.

Further Read:

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/azure-ad-b2c 

Dynamics 365 Portal – Authentication Series (Part 1) – The Basics

I’ve been recently deployed a quite complex Dynamics 365 portal solution involving a custom authentication provider and other features such as Power BI Embedded and SharePoint integration.

In this series, I’ll discuss in more detail about the authentication side based on my lesson learned out of this challenge to get them working properly. My plan is to discuss the following topics in this series:

  1. The basic – Local Auth
  2. External Auth – Using Azure AD & Azure AD B2C
  3. External Auth – 3rd party ID provider
  4. Some tips and tricks around

Before we begin, I would admit that I’m not a portal expert, I learned the concept and knowledge from these great experts: Colin Vermander, Nick Doelman, George Doubinski and Dileep Singh. So, credit is to my great “teachers”.

So, to begin with, let’s try to understand the authentication methods that the Dynamics 365 portal supports (https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-portal-authentication).

In a nutshell, Dynamics 365 portal’s authentication is based on the ASP.Net Identity, which is based on the OWIN Framework (The OWIN framework is the “jargon” that seems to be commonly being used by the auth provider in their documentation, so always good to know and understand how it works/behaves).

There are 2 methods of authentications in Dynamics 365 Portal:

  1. Local Authentication

Purely based on Dynamics 365 Contact record to store the authentication details.

  1. External Authentication

Utilising the ASP.Net Identity API to integrate with the external ID providers using either OpenID Connect or OAuth or SAML.

To ensure the portal authentication to work properly, ensure the following solutions exist in the environment. These solutions typically will always be there after the portal instance being provisioned, but I had a case where the overall authentication process is not working properly due to missing one of the following solutions (if you encountered the same issue as me, log a support ticket and the support team can add the missing solution fairly quickly).

Solutions.png

The minimum viable option of the authentication would be using the local authentication. However, I would recommend to minimise the usage of the local authentication method and use External Authentication (if possible Azure AD-family) as much as possible, not only for the security compliance but also future proofing your portal investment. This is based on Colin Vermander’s blog post from last year: https://colinvermander.com/2018/05/19/dynamics-365-portals-authentication-deprecation/

Even though the link in the article is no longer showing the deprecation on it, but I reckon the intent to push to Azure AD B2C is still there.

Local Authentication in a Glance

When you are using the Local Authentication, the portal solution is storing the user creds within the contact entity. Password is stored as hashed text within Dynamics 365 (even though Dynamics handles the security and encryption at rest, this could be an “alarming” thing when the system is being audited by security experts. Thus, recommended to use external idp).

username password.png

Some of the notable site settings that construct the basic behaviour of the local authentication in Dynamics 365 Portal:

  • Authentication/Registration/Enabled
  • Authentication/Registration/LocalLoginEnabled
  • Authentication/Registration/OpenRegistrationEnabled
  • Authentication/Registration/InvitationEnabled
  • Authentication/Registration/RememberMeEnabled
  • Authentication/Registration/ResetPasswordEnabled
  • Authentication/Registration/ResetPasswordRequiresConfirmedEmail

The technical description of those settings are available in this documentation article: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/set-authentication-identity

In the next post, I will discuss on how to configure the authentication using Azure AD & Azure AD B2C.

Update to the Unified Interface in the October 2018 Release

Microsoft product team just shared the latest update for Unified Interface in the October 2018 release. This is important especially for those who have started embracing Unifed Interface in their organisations. Note: These Unified Interface updates were not highlighted in the October Release Notes and there is no official article/documentation that stating this yet.

Overall, the update is to address the feedback around the usability and adoption of Unified Interface, primarily around the navigation and colour scheme. To keep in mind, this update is going to be automatically applied to the organisations with v.9 onwards, without the “Opt-In” feature (Related to the quite recent announcement from Microsoft about the continuous update of Dynamics 365). It means if your organisation has embraced the Unified Interface, there might be a slight change to the training material (if any) and preparing communications to the end users so that they are aware of this UI/UX change to the Unified Interface.

The changes are as follow:

Before

thumbnail_image001.png

After

thumbnail_image002.png

Sitemap changes:

  • Site map will be expanded by default, with the option to collapse, to improve user recall and learning.
  • Simplified IA: MRU (recent) and favorites (pinned) moved to top level, always visible. No more entity level MRU.
  • No more tabbed sitemap. Bottom flyout used to select areas. To reduce icon overload, colorized tiles replaced area icons.
  • New color scheme (black on gray) to improve navigation discovery.

Commanding changes:

  • Dark text on light background to group commanding with the content area it effects
  • New colored icons and hover effect distinguish different commands and highlights interactive regions

Affected viewport width
These changes are aimed at improving user experience for desktop browser users at widths above 480.

Leveraging Microsoft Flow to be your API Engine – Low Code Approach

Recently I’ve been experimenting with Microsoft Flow and its counterpart, Logic Apps. A thing that I noticed could become a game changer in designing a business solution these days is that Microsoft Flow can be turned into an API engine. In my example, I’m going to create a very simple API to send a message to my Skype for Business and reply back with the response whether the API call is successful or not.

The first step is by registering the HTTP Request trigger in the Flow step:

HTTP_Request_Trigger.png

As any typical API, you will need to specify the data payload. To generate the payload schema, we can use the “Use sample payload to generate schema”. I’m going to use a simple payload to send the message:

{
      “message”:”payload for skype”
}
Payload_generator.png
Once generated, this will create the schema for you
HTTP_Request_Trigger_with_schema.png
To ensure that the payload schema is validated on the HTTP request by clicking the Settings option:
Settings.png
And turn the Schema Validation to On
Schema_Validation_On.png
The next step is to register the action that you would like to perform (you could be creative here with the available connectors for Microsoft Flow or you can come up with your custom connector).
In my sample, I’m going to add the Skype for Business action: Send Instant Message
Send_skype_message.png
As any typical API, we will need to provide the response appropriately. In this example, I’ll just implement the success response. Exception handling will be discussed on a separate blog post.
response.png
Once finished, save the flow and the HTTP Request step will generate the API endpoint:
endpoint.PNG
To test the endpoint, you could simply use Postman (or any tools to stimulate HTTP request) to trigger it:
Postman.png
And here’s the result:
Skype.png
Skype2.png

Conclusion

To create a low-code API is now become very simple with Microsoft Flow. With the available connectors and actions, workflow-based API can be achieved in configurations!