The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
Personalized Community is here!
Quickly customize your community to find the content you seek.
Work or School Accounts Now Enabled in Community!
On May 12 Work or School Accounts were enabled in Community, along with Microsoft accounts (MSA). This allows seamless navigation between Community, Dynamics 365 applications, and Azure Active Directory enabled sites while logged into your Work or School account.
Read more | Managing Accounts
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
In my previous post, I gave an overview of authentication with Power Apps Portals, and I mentioned that external authentication is the way to go. In this post, I’ll dive a bit deeper into external authentication.
Power Apps Portals supports four protocols for external authentication:
WS-Federation and SAML 2.0 are older technologies which I don’t see being used as much with Power Apps Portals, but they are still very much supported. I believe WS-Federation is often used to include ADFS as an identity provider, whereas SAML 2.0 is used in a variety of different applications. Power Apps Portals supports having multiple different SAML 2.0 identity providers configured for a single Portal, whereas I believe only a single WS-Federation identity provider is supported.
For OAuth2, Portals supports a specific list of identity providers:
Unfortunately, unlike the other types of external authentication types, if your OAuth2 provider of choice isn’t on the list, it isn’t supported unless is also supports one of the other types of authentication.
The newest type of external authentication protocol is Open ID Connect, which is built on top of OAuth2.
As an aside, the “auth” in OAuth doesn’t stand for authentication, but actually authorization. OAuth is meant for authorizing access to services – think of giving permissions to apps that will post to your Facebook feed on your behalf. It was never really meant for authentication (which is verifying identity). Open ID Connect is a layer on top of OAuth2 specifically meant for authentication.
Power Apps Portals supports any compliant Open ID Connect identity provider, and you can configure as many as you’d like.
If you have an identity provider that happens to support multiple protocols, I recommend using Open ID Connect.
A contact can be related to many external identities – this means that different logins can result in the same contact logging in.
These various identities can be managed on the Manage External Identities page in the Profile section on the Portal. Once logged in, users can add more external identities, or remove existing ones (although they can never remove the last one).
As an example, if someone originally signs up using Facebook, they can then also associate a LinkedIn profile with their Portal account. Then, logging in with either account will result in the same experience.
For external authentication, there is actually a separate entity in CDS that stores the information needed to link a contact to their external identity – this entity is called External Identity. An External Identity record is made up of two main fields: the username and the identity provider. Long story short, when someone logs into the Portal, the Portal uses a combination of which identity provider the user logged in with, and the username returned by that identity provider to find the appropriate External Identity record in CDS. The contact record associated to that External Identity record is then set as the currently logged in contact.
It’s important to note the “username” that the Portal sees from an identity provider is not typically the username that the user enters. It is more often a GUID-type identifier. Also, most identity providers will give out “usernames” that are specific to the app that is being used for authentication. So even if you use the same Facebook account to login into different systems, each of those systems will see a different “username”. So the username field in External Identity doesn’t usually mean much to anyone except the identity provider itself.
In my next post I’m going to cover Microsoft’s preferred identity provider, Azure AD B2C, which is enabled on the Portal using Open ID Connect.
The post Power Apps Portals: External Authentication appeared first on Engineered Code.
Business Applications communities