I am stumped trying to find a similar idea on how we can achieve this.
We are currently using a model-driven power app/Dataverse to house school applications. Once an application is submitted, our representatives will begin updating the application record "Application Status" custom field as they are going through the various steps.
Our partner wants to create a external website (just simple HTML/CSS/JavaScript) to display an application lookup where applicants can type in their application ID or send applicants direct-links to view the status of their application. (example: domain.com/application-status/?appid=1234)
This external, public website would have to connect to our dataverse/power app via the web api to make the request and display it to the applicant searching/viewing the website.
How can this be achieved? All I have read is that the user looking up data will need to have a Microsoft account and authenticated in our environment to view the data.
Can someone point me in the right direct on how to get this done (article or existing thread). Your help is highly appreciated.
This is normally being handled by the use of a PowerPlatform Portal.
Portals are designed to allow interactions with B2B/B2C.
This is, however, a hefty price tag.
Another way is to make your website use Rest API calls to your Dataverse tables.
To enable these, you need to create a client application registration in Azure and add this application user in your environment as an application user. Once registered, assign the appropriate rights(Sysadmin, Syscustomizer, whatever you want) and you can access your environment in two steps:
Generate an access token based on the scope of your environment, client id, and client secret.
Use the access token your application user has given to do your CRUD operations.
Related
I'm trying to better understand how to make use of OIDC/OAuth in securing a restful API, but I keep getting lost in terminology. Also when I research this question most of the answers are for Single Page Apps, so for purposes of this question assume the API will not be used for an SPA.
Assumptions:
Customers will access a restful API to interact with <Service>.
It is expected that customers will create automated scripts, or custom application in their own system to call the API.
Once setup it is not expected that there will be a real person who can provide credentials every time the API is called.
<Service> uses a 3rd party IDP to store and manage users.
3rd part IDP implements OIDC/Oauth and that is how it should be integrated into <Service>
Questions:
What OIDC/OAuth flow should be used in this situation?
What credentials should be provided to the customer? client-id/client-secret or something else?
What tokens can/should be used to communicate information about the "user"? E.g. Who they are/what they can do.
How should those tokens be validated?
Can you point me to any good diagrams/resources that explain this specific use case?
Am I missing anything important in the workflow?
It sounds like these are the requirements, if I am not misunderstanding you. The solution contains not just your own code and is more of a data modelling question than an OAuth one.
R1: Your company provides an API to business partners
R2. Business partners call it from their own applications, which they can develop however they see fit
R3. User authentication will be managed by each business partner, resulting in a unique ID per user
R4. You need to map these user IDs to users + resources in your own system
OAUTH
Partner applications should use the client credentials flow to get an access token to call the API. Each business partner would use a different credential for their set of users.
Using your own IDP to store users does not seem to make sense, since you do not seem to have an authentication relationship with the actual end users.
Access tokens issued to business partners would not be user specific by default. It is possible that a custom claim to identify the user could be included in access tokens - this would have to be developed in a custom manner such as via a custom header, since it is not part of the client credentials flow.
Access tokens would be verified in a standard OAuth manner to identify the partner - and possibly the end user.
DATA
Model users in your own system to have these fields, then store resources (such as orders) mapped against the User ID:
User ID (your generated value)
Partner ID (company the user is from)
External User ID (an ID that is easy for partners to supply)
Typically each partner would also have an entry in one of your database tables that includes a Client ID, name etc.
If you can't include a custom User ID claim in access tokens, partners have to tell you what user they are operating on when they call the API, supplying the external user ID:
POST /users/2569/orders
Your API authorization needs to ensure that calls from Partner A cannot access any resources from Partner B. In the above data you have all the fields you need to enable this.
SUMMARY
So it feels like you need to define the interface for your own APIs, based on how they will be called from the back end of partner apps. Hopefully the above hints help with this.
I recently switched to a new company where my manager wants me to develop entirely new cloud based project in MVC. I have never worked on a project from the start and I think this is a good opportunity for me to lead.
However, I think the requirements of the clients are bit confusing.
Here is what he wants:
Client should be able to access the cloud hosted application from his network with single sign on. He wants to use his active directory for that.
There are different users in active directory, they will have different roles (I think we can handle this on database side. Create different roles and assign roles to users).
Client has to add vendor info in the application. But for this, system should send an email to vendor with the url of the cloud application. He wants user to login to the application using 2 Factor Authentication. So, send dummy password with url, and send OTP to his mobile number. Just like registering to any system.
Now my questions are:
Is it possible to have 2 different types of login mechanisms in the same application? SSO for client and 2FA for outside vendors?
If yes, could you please guide me in the right direction?
what things I need? Which framework, design pattern should I prefer?
How do I proceed ?
I'm writing an application that will be the backend for a react website. The website is to be used by our customers, but we will fully control the permissions of the user. We have decided to use Azure AD to secure requests, but will also be exposing the API for end users to use directly if desired.
My understanding is in Azure AD I will have to create an application that will allow web based implicit authentication (for the react site), as well as a native application that will allow a dameon based application to authenticate to the API.
This I believe means I will have two audience ids in my application.
I'm trying to get claims to include groups, and I can see if I edit the meta data of both applicaitons in azure AD to include "groupMembershipClaims": "SecurityGroup" I can get claims with the group IDs in, but no names.
I think I can also use appRoles to set roles the application uses, but I've yet to get that to come through as claims in the JWT, but I'm assuming it can be done, however I'd need to setup the roles on each applicaiton, then add the user twice which isn't really ideal. I also think that because my app is multi-teanated that external users could use this to set their own permissions, which isn't what I want to do.
Sorry I'm just totally lost and the documentation is beyond confusing given how frequently this appears to change!
TLDR: Do I need two applicaitons configured in azure ad, and if so whats the best way to set permissions (claims). Also is oAuth 2 the right choice here, or should I look at open id?
Right away I gotta fix one misunderstanding.
Daemon apps usually have to be registered as Web/API, i.e. publicClient: false.
That's because a native app can't have client secrets.
Of course the daemon can't run on a user's device then.
Since that's what a native app. An app that runs on a user's device.
This I believe means I will have two audience ids in my application.
You will have two applications, at least. If you want, the back-end and React front can share one app (with implicit flow enabled). And the daemon will need another registration.
I'm trying to get claims to include groups, and I can see if I edit the meta data of both applicaitons in azure AD to include "groupMembershipClaims": "SecurityGroup" I can get claims with the group IDs in, but no names.
Yes, ids are included only. If you need names, you go to Graph API to get them. But why do you need them? For display? Otherwise, you need to be using the ids to setup permissions. Names always change and then your code breaks.
I think I can also use appRoles to set roles the application uses, but I've yet to get that to come through as claims in the JWT, but I'm assuming it can be done, however I'd need to setup the roles on each applicaiton, then add the user twice which isn't really ideal. I also think that because my app is multi-teanated that external users could use this to set their own permissions, which isn't what I want to do.
Your thoughts for multi-tenant scenarios are correct. If you did want to implement these though, I made an article on it: https://joonasw.net/view/defining-permissions-and-roles-in-aad.
Why would you need to setup the roles in multiple apps though? Wouldn't they only apply in the web app?
If the native app is a daemon, there is no user.
Overall, I can see your problem. You have people from other orgs, who want access to your app, but you want to control their access rights.
Honestly, the best way might be to make the app single-tenant in some tenant which you control. Then invite the external users there as guests (there's an API for this). Then you can assign them roles by using groups or appRoles.
If I misunderstood something, drop a comment and I'll fix up my answer.
Azure AD is of course a powerful system, though I also find the OAuth aspects confusing since these aspects are very mixed up:
Standards Based OAuth 2.0 and Open Id Connect
Microsoft Vendor Specific Behaviour
ROLE RELATED ANSWERS
This is not an area I know much about - Juunas seems like a great guy to help you with this.
OAUTH STANDARDS AND AZURE
I struggled through this a while back for a tutorial based OAuth blog I'm writing. Maybe some of the stuff I learned and wrote up is useful to you.
AZURE SPA AND API CODE SAMPLE
My sample shows how to use the Implicit Flow in an SPA to log the user in via Azure AD, then how to validate received tokens in a custom API:
Code Sample
Write Up
Not sure how much of this is relevant to your use case, but I hope it helps a little on the tech side of things...
I have simple ASP.NET MVC survey generator, that based on the URL displays various forms and persists data input from user:
http://survey.mydomain.com/ConferenceFeedback
http://survey.mydomain.com/DailyReport
etc.
Some of these subapps should be accessible by everyone, some by specific set of users. My user store is Azure AD. Is there is any Azure AD related feature that is a good match for my authorization scenario, where I could assign user rights on Azure side and just validate some claims or roles in my app per user request?
You might want to look into application roles. You can define roles representing the various subapps you want to model, and you can assign users to them accordingly. On the application side, you can examine the incoming claims set and decide whether the user has the necessary role claims for accessing the portion of the app they are requesting. See https://github.com/Azure-Samples/active-directory-dotnet-webapp-roleclaims for a sample app demonstrating the approach.
I have been working on an Angular/Ionic application and am using the OAuth.io plugin to handle a facebook login to gain a user's information. From that I derive a simple database name based on the user's firstname and their Facebook ID number.
What I am wanting to do would be to sync this local pouchDB instance to an online CouchDB instance (currently using http://iriscouch.com) for replication to a desktop app, or something similar. The piece I am missing is how to handle user authentication/authorization to be able to only read and write to their own database and no one else's as all of the code currently lives on the client side with no app server to handle any login aside from the OAuth.io plugin.
Is this possible to handle without adding an app server layer, and without manual intervention to create a user on the CouchDB instance?
Currently you can only do per-user read-write permissions in CouchDB by having an additional process on the server side (details), which would be troublesome for you since you're using IrisCouch, so you'd need a separate server somewhere to host this process.
A few alternative options are available to you right now:
Couchbase, which has per-user databases
Janus, which works using Mozilla Persona rather than Facebook ID, and isn't ready yet, but should be unveiled shortly