cmty_blog_detail (2024)

cmty_blog_detail (1)

If you’re new to Power Apps Portals, or you’re an Adxstudio veteran, Portal authentication can be a tricky concept – there are a lot of options, and since we’re dealing with getting access to potentially sensitive data, you want to make sure you’re doing it right. I’ve got a few posts lined up on this subject, but I thought I’d start with a general overview of how authentication works in Power Apps Portals.

Logged In Portals Users Are Always Contacts

The first thing you need to understand is that all authentication is done in reference to a contact in CDS. Even if you are building an employee self-service portal, and you are using Azure AD to log in, and those people are licensed Power Apps or Dynamics 365 users, they still need to have a contact record to log into a Portal. The “user” object that represents the currently logged in user is always a contact, and never a system user.

When we talked about the options for Portal authentication, we are talking about who manages the actual usernames and passwords that are associated to contacts in CDS.

Two Main Types

At a high level, there are two types of authentication in Power Apps Portals: local and external.

Local authentication is when the username and password information is stored directly in CDS on the contact record. Usernames can either be the contact’s email address, or a special username field. A hashed version of the user’s password is stored, which makes it possible to verify that the correct password has been entered, but makes it impossible to retrieve their password from the database. While convenient and easy to use, local authentication has be deprecated by Microsoft, and should be avoided.

External authentication is when something outside of CDS is managing usernames and passwords – think Microsoft Accounts, Facebook, Twitter, etc. Users log in with credentials from other services, which are associated with a contact in CDS. These external authentication managers are known as identity providers, and there are a few different protocols for identity management. Portals supports four main external identity protocols: OAuth2, SAML, WS-Federation and Open ID Connect.

One of the great things about Portal authentication is that you don’t need to pick just one of these options – you can enable as many as you want. When you go to the sign in page on a Portal, the user is given a choice between all the configured identity providers.

So why doesn’t Microsoft want you to use local authentication? Well I can’t speak for them, but I can take a guess: Microsoft has a team that is focused on technology meant for authenticating people into applications like Power Apps Portals, and it’s not the Power Apps Portals team – instead, it is the team responsible for Azure AD B2C. I’ll be covering Azure AD B2C in a future post but, in short, it is a single identity provider that itself supports other identity providers like Facebook, Twitter, etc. Rather than Portals having to support Open ID Connect, OAuth2, SAML 2.0, etc, wouldn’t it be nicer if Portals just relied on something else that does authentication for a living?

Also, passing authentication off to external identity providers means Portals no longer needs to worry about saving username, passwords, and doesn’t have to worry about things like password resets. All things which are a pain and better dealt with by people who live and breath authentication.

How Is Authentication Configured?

I’m not going to get into the details of how to setup each of these types of authentication, since that documentation already exists on the official Portals documentation site. However, what I’ll mention here is that, at a high level, authentication is configured using Site Settings. Configuring authentication typically involves three or more Site Settings per provider.

How Do Contacts Get Usernames and Passwords?

While all users of a Portal must be a contact, not all contacts can log into the Portal. How do you go about associating a username and password (either local or external) with a contact?

There are typically two ways that contacts get associated with login information – either via registration or invitation.

Registration is used when the contact doesn’t already exist in CDS. If you’ve enabled open registration on your Portal, new users can sign into your Portal using any of the configured identity providers (or local authentication), which will create a bare-bones contact record associated with those login credentials. After logging in, the user will be presented with their profile page, which gives them the opportunity to fill out more details like their name, contact info, etc.

The invitation process is used when contacts already exist in your system. In this case, you don’t want users to register using open registration, as this will create the blank contacts mentioned earlier. Instead, you want to use an invitation code process to invite them to your Portal. Typically this means sending them an email with a unique code that they can enter when signing into the Portal – with this unique code, the Portal knows to associate the login information with the existing contact instead of creating a new blank one. For more details on the invitation process, see this documentation.

In my next post I’m going to dive a bit deeper into the various protocol supported for external authentication.

The post Power Apps Portals: Authentication Overview appeared first on Engineered Code.

cmty_blog_detail (2024)
Top Articles
How to Buy on eBay Safely and Avoid Scams: Ultimate Guide
NFT Environmental Impact - NFT Carbon Footprint Demystified
Automated refuse, recycling for most residences; schedule announced | Lehigh Valley Press
Libiyi Sawsharpener
Nwi Police Blotter
How to change your Android phone's default Google account
Call of Duty: NEXT Event Intel, How to Watch, and Tune In Rewards
Ohiohealth Esource Employee Login
Edible Arrangements Keller
Blue Beetle Showtimes Near Regal Swamp Fox
My.doculivery.com/Crowncork
Hair Love Salon Bradley Beach
Sivir Urf Runes
9044906381
Costco Gas Foster City
Enterprise Car Sales Jacksonville Used Cars
Dutch Bros San Angelo Tx
Cyndaquil Gen 4 Learnset
Nesz_R Tanjiro
The best TV and film to watch this week - A Very Royal Scandal to Tulsa King
Gentle Dental Northpointe
Rust Belt Revival Auctions
Reicks View Farms Grain Bids
13301 South Orange Blossom Trail
Craftybase Coupon
Yayo - RimWorld Wiki
Kqelwaob
The Posturepedic Difference | Sealy New Zealand
Jambus - Definition, Beispiele, Merkmale, Wirkung
Wake County Court Records | NorthCarolinaCourtRecords.us
Song That Goes Yeah Yeah Yeah Yeah Sounds Like Mgmt
What Time Does Walmart Auto Center Open
Pickle Juiced 1234
Goodwill Houston Select Stores Photos
The Vélodrome d'Hiver (Vél d'Hiv) Roundup
ENDOCRINOLOGY-PSR in Lewes, DE for Beebe Healthcare
What Does Code 898 Mean On Irs Transcript
Columbia Ms Buy Sell Trade
Htb Forums
Sept Month Weather
This 85-year-old mom co-signed her daughter's student loan years ago. Now she fears the lender may take her house
The Attleboro Sun Chronicle Obituaries
Exam With A Social Studies Section Crossword
'The Nun II' Ending Explained: Does the Immortal Valak Die This Time?
News & Events | Pi Recordings
Turok: Dinosaur Hunter
Wieting Funeral Home '' Obituaries
Autozone Battery Hold Down
Ingersoll Greenwood Funeral Home Obituaries
Tamilyogi Cc
Latest Posts
Article information

Author: Gregorio Kreiger

Last Updated:

Views: 6535

Rating: 4.7 / 5 (57 voted)

Reviews: 80% of readers found this page helpful

Author information

Name: Gregorio Kreiger

Birthday: 1994-12-18

Address: 89212 Tracey Ramp, Sunside, MT 08453-0951

Phone: +9014805370218

Job: Customer Designer

Hobby: Mountain biking, Orienteering, Hiking, Sewing, Backpacking, Mushroom hunting, Backpacking

Introduction: My name is Gregorio Kreiger, I am a tender, brainy, enthusiastic, combative, agreeable, gentle, gentle person who loves writing and wants to share my knowledge and understanding with you.