So, Azure AD has me a bit confused and I'm wondering if I need Azure AD B2C or not for what I'm trying to accomplish.
I'm setting up a asp.net core mvc entity framework webapp with the intention to sell subscriptions to users. These users can log in, add data and invite other users to join their group where they then can be assigned a role.
Am I right to think that I need to set up a B2C single tenant and use the Graph api to code groups and roles? Or can azure do this for me? Basically, what's best practices for setting up this kind of user/payment model?
Related
I am new to dynamics portals and want to implement authentication for external users using Azure B2C Authentication.
I followed the below link and was able to configure B2C.
https://learn.microsoft.com/en-us/power-apps/maker/portals/configure/configure-azure-ad-b2c-provider
Question -
How can I limit the user creation only for the organisation i am targetting.
Foreg - If i am creating this portal for XYZ Company and I only want users from this organization to signup on the portal. How can i achieve this?
So that i do not get unnecessary contacts in my portal
We have single page app (Angular front end and .NET Core Web API) using Azure AD for authentication. Both front end and and Web API are registered in the same tenant and WebUI has permissions to call the Web API. This Web API uses a few other internal Web API's as well.
We have a new requirement in the app to allow access to certain areas of the app to external users who need to register first. So now the app need to authenticate both existing AD Users plus external users.
My question is if this is possible in a single application? And if yes what is the recommended approach for authenticating both corporate and external users?
As you need to use register feature, you will need to use Azure AD B2C, and it supports multi providers for a valid user flow.
For example, if you want azure ad users and external users to use your application. You can choose OpenID Connect(Azure AD) and Local Account(or other social accounts). In the login page, users can choose to sign up or use Azure AD account to login directly.
Steps:
Just keep your Wep Apps and api apps in the existing tenant. You need to create a Azure AD B2C tenant, create a user sign up/in flow, configure the providers for the user flow.
Reference:
Create B2C tenant
Create user flow
Add identity providers
Configure your original Azure AD application to the identity provider
I'm in throws of moving our security architecture from ASP.NET Core Identity to Azure AD V2 with MSAL.js. We used a lot of Roles with the ASP.NET Core Identity implementation and the information was managed in the database using the web application. The pattern I'm abandoning is similar to this one.
https://www.dotnetcurry.com/aspnet-core/role-based-security
Azure AD with MSAL is working. The tokens are being created and passed and the local Web API Endpoints decorated with the generic [Authorize] attribute are being honored as you would expect. Web API Endpoints decorated with [Authorize(Roles= "Fee, Foo, Fi, Fum")] are throwing a 401 unauthorized error.
I'm not sure where to go from here. Do I write a CustomAuthorize attribute override for Web API and go back to the database and grab the roles. (probably match the DB defined roles to the user based on email address)
OR
Is there a way to implement roles natively with Azure AD V2?
I'm not sure whats the best course of action from here. Documentation and Code samples seem limited. It would sure be nice to just throw a AD User in a Group and have the Group be respected as a Role in the Web API. On the other hand, It's nice to have Role delegation handled within the confines of the Web Application.
Any advice, experience or interest would be greatly appreciated.
Answer
Follow up to my question. #Marc , You're correct, after looking at the token the Roles are not present. Adding Roles to the token seems pretty straight forward. You need to Patch the graph schema to include them, Configure the roles and assign them to users as needed thru AAD.
Or that's how it looks at first glance. After digging a deeper, it requires a P1 or P2 Enterprise license which only costs an additional 6$ per month per user. This will literally double the cost of hosting email in the cloud for us.
Alternatively I wrote a CustomAuthAttribute for WebAPI and tied User & Roles together on the server backend. Roles can still be managed via the web application and users can still login using Active Directory Credentials.
I recall that the id token returned in implicit flow (the one you use with JS) does not include app roles (or groups). I cannot find any docs confirming that but see others who got around the issue (so the issue must be there) by using Graph to get the roles (or groups).
You can capture the token you receive from AAD and view it using https://jwt.ms to see whether roles are included in it.
I have a custom application for internal use only where currently users are created by a super admin. Some of the users are from within the business and some external e.g. suppliers/customers.
I'm looking for a way to integrate MS Active Directory as a login option but want to be able to restrict which users from the business can actually use this method.
I have search through all the MS docs and have all the documentation on the different oauth approaches but not sure which one would be suitable for my needs.
I am thinking that perhaps i need to give the admin a way to browse the AD and select the users that can login which then creates inactive user accounts in the mysql database with some sort of MS user ID. Then provide a 'Sign in with MS' button that does the usual auth redirection process to MS and back to the site. At that point I can check an ID and if that matches an allowed user account and if so, sync the rest of the data e.g. name, email, phone etc..
Links I've already found:
https://learn.microsoft.com/en-gb/azure/active-directory/develop/authentication-scenarios
https://learn.microsoft.com/en-gb/graph/tutorials/php
https://github.com/microsoftgraph/msgraph-training-phpapp/tree/master/Demos/03-add-msgraph
Your first order of business is enabling a user to sign in to the Laravel-based app. For this, I strongly recommend not trying to re-invent the wheel (at least not completely), and make use of an existing Laravel package. Laravel Socialite is probably the best place to start, since it has a long list of existing community-provided Socialite providers, including three which work with Azure AD already: Microsoft, Microsoft-Graph and Microsoft-Azure. (Note: Though I haven't tested any of these myself, the first two seem to be the most promising, as they use the newer v2 endpoint.)
When it comes to authorization (controlling access), you have two options:
Control at Azure AD
Once you've got the app integrated with Azure AD, you can configure the app in Azure AD to require user assignment, and then control access to the app by assigning (or not) users to the app. Users who are not assigned won't even make it past the sign-in page.
You can use Azure AD's existing experiences for managing user and role assignment for the app, or you could go all-out and build this experience directly into the Laravel-based app itself, making use of the Azure AD Graph API to create the [app role assignments](https://learn.microsoft.com/en-us/previous-versions/azure/ad/graph/api/entity-and-complex-type-reference#approleassignment-entity and user picker experience.
Hint: In either case, remember that you can make the app "superuser" an "owner" of the app in Azure AD (Azure AD > Enterprise apps > (app) > Owners), which will allow them to assign users without needing to give them any additional privileges in Azure AD.
Control at the app
In this approach, you allow all users to sign in to the app with Azure AD, but then you use your app's own authorization logic to decide who makes it any further, and what roles they get in the app.
In reality, you will most likely find the best approach is to use a combination of the two, with some of the authorization enforced by Azure AD and the next level enforced by the app itself.
If you would do it in this way, it will be necessary that the super-admin has always this permissions in the AAD. From my point of view it is less practical.
I would perfer such app-assigments with help of Service Principal. You assign a role (look for app roles) to the user and then your business logic must decide which permissions the user has. If you would use the app roles feature, then you can restrict access to the role with it's help. All the user can login, but only users with a specific role would be able to see a content of the app.
I hope this hints can help to find a right direction, but there is no silver bullet solution... :/
We are currently using Azure Access Control Services (***.accesscontrol.windows.net) to allow customers with personally-managed Microsoft Accounts (Identity Provider) to sign in to our customer self-service portals (Relying Party Applications), which are Angular apps powered by Web API services. In our Access Control Services we are currently passing through the nameidentifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier claim from Windows Live ID to the relying party APIs, which match that token to an identity in our applications.
We are looking to support both Enterprise and Personal Microsoft Accounts with the Azure AD v2.0 service, but do not understand how to migrate our existing users to the new system. The code examples suggest that the OWIN middleware returns the NameIdentifier claim from the user's Identity Provider, but if that Identity Provider is the same Microsoft Account (aka Windows Live ID), will that be the same NameIdentifier we are currently receiving via Access Control Services pass-through?
Any help and/or documentation that clarifies how this transition is intended to work would be appreciated.
If the nameidentifier coming out of ACS is the randomly generated value then you're kind of stuck because that value is unique to the ACS/RP/User. If it's returning the actual Live ID then it'll obviously only match if the Azure AD user has the same email address.
I don't know if any documentation out there that describes how to handle this situation. My recommendation is to just require a one-time authentication from each source within the same session and marry the two results. That would basically mean
authenticate to Azure AD
Your app: Hey you don't have any user details, do you want to associate a Live ID?
Authenticate Live ID
Associate Live ID with Azure AD
Then if they want to sign in with either accounts in the future you have a link between the two.