I am new to Azure Active Directory and I am bit confused about the concept and its capabilities.
I am developing an API and a native client application that will consume this API. I registered both the API and the client app in AAD and
I managed the authorization of the client application using my Admin credentials (Azure Account). But I still don't get it.
I want the users of my client application to be able to register to the app service and then use it.
Should I handle that myself within the API (user/password in database) ?
Or
programmatically create users in AAD when users signup for my application ?
Which solution is better if I plan to offer more APIs ?
If using AAD is the case I will be grateful if you provide explanations, useful links or code examples if possible.
Your question is quite broad, and is comprised of several questions, so it is hard to answer concisely.
If your users are already in your Azure AD, you should use that as the user store. If however, they are outside of your organization, you could use Azure AD B2C, which contains functionality for selfservice account creation. Or take a look at https://stackoverflow.com/a/16068340 for a suggestion on how to use AAD for public users.
If the users are already present in your AAD, and you haven't set up user assignment on the application in AAD, they can already log on to the application.
You can use role based security to grant users different levels of access to the API methods if you are interested in that.
Related
We want to build a Sass application. We separated individual servers/instances and DB for every customer.
Our sass model:
As part of our app, we want to use Azure Ad (Multitenant) for Identity management. We have a few cases:
Our few customers don't have organizational email then how can we manage them in Azure ad (they have maybe Gmail)
We decided to set application-level roles/permission for every API endpoint, for this scenario how to manage those roles/permission in the azure ad, Who is responsible for assigning those roles to every client's users after onboarding?
For every company, we have a users limit then how can we restrict a company's users (like only 5 users from a company able to use our application)
We have a special case like module-based permission for our customers. How can we manage this?
When an organization/company starts to use our application, If we want to give them an admin panel where they are able to manage their permission-related stuff, like adding or removing roles to their users, is it possible? (all roles/permissions are fixed from our side, they only assigned those roles to their users)
++Our few customers don't have organizational email then how can we manage them in Azure ad
->You can invite them into the tenant, then they can use their gmail account to sign in the tenant.
++set application-level roles/permission for every API endpoint ... how to manage... responsible for assigning ..
->I can't understand it but I think it's based on your requirement, user who has admin role may take the responsibility.
++have a users limit then how can we restrict a company's users...
->follow this document to set who can use the azure ad application you registered for the authentication to sign in the application.
++module-based permission for our customers
-> role management?
++adding or removing roles to their users, is it possible
-> if there's no admin panel for each company, then you may follow this answer to set role for users and validate if the access token contained correct role so that this user can access the page.
Let's assume you had an application which has a frontend app as the client and an web api project as the server. Then in the front app, you need to integrate msal lib to let users sign in with their user#xx.onmicrosoft.com account or gmail account. Then the frontend app need to generate access token and call api via it. The token should contain enough information so that the api can validate if the token had enough priority to get the data. And in the frontend app, you also need to control the page direct via the access token or id token.
Then here's the official sample document.
In the end, azure ad provides user management and sign in feature. It also provides api management feature. If you have any other questions, I recommend you creating a new question with more specific requirement.
I am missing something important here! I just don’t know what to ask for. Maybe I’m getting it all wrong, so feel free to send me in another direction.
To keep things simple – let’s assume that I want to build an app in C# that anyone can download and install on their PC.
The app should be able to read and make changes to the current users Outlook 365 calendar.
So far, I’ve learned through the MS Graph Explorer, that I can use rest calls to manipulate data in my own calendar. Sure – it requires that I login before I can use my own data rather than “demo” data.
I’ve searched for tutorials on how to build Graph applications, to go with the same approach as the MS Graph Explorer. But every tutorial I’ve see so far requires me to register the app in Azure before it will work.
What I don’t understand is – how can the login on the web page with MS Graph Explorer give me access to my calendar without it being registered in my Azure account?
Like – if I create an app as described above – how can it work in any installation if it was not registered in the users Azure portal?
What am I missing?
Basically I’m asking how to replicate the authentication method that is used on the web page with the MS Graph Explorer.
MS Graph Explorer, like the app you would need to register, is a multi-tenant application.
When you register an app, you can choose if it allows sign in from only the current tenant, from any tenant, or from any tenant and personal MS accounts.
So you do need to register the app, but only in your AAD tenant.
Then when you authenticate the user in the app, you use one of these as the authority:
https://login.microsoftonline.com/common: allows authentication from any AAD tenant and with personal MS accounts
https://login.microsoftonline.com/organizations: allows authentication from any AAD tenant (no personal MS accounts)
The user will then authenticate to their own home tenant and will be required to give consent to scopes required by your app (e.g. permission to read/write calendar data for current user).
After consent, a service principal/enterprise app is created in the user's tenant (if it is an AAD user).
This SP is the local representation of the app.
You can read more about multi-tenancy in the docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/single-and-multi-tenant-apps
We have a client that currently use a ERP-system to store all their clients. This is a closed source ERP so they can not change the authentication flow. Right now they have an authentication API that various other APIs use but development is slow. They are now facing a challenge in that they need to bring more systems in and given the current structure this takes time since their APIs are tightly coupled with the rest of the systems. They absolutely wan't to avoid other departments from creating applications with their own authentication simply because they cannot keep their pace up.
They wan't to keep SSO for all their customer systems but have better control which users are allowed to do what.
I have been reading about Azure Active Directory B2C and it seems really great. We use Azure Active Directory (AAD) authentication for our internal applications and it works flawlessly most of the time.
Here comes the two part question:
Is it possible to use Azure AD B2C and still keep users in the ERP? For example if we can connect Azure AD B2C to send a request to a service that responds with user data if that user exists given that the credentials are correct.
Extension of question 1. The current ERP-systems gives the user an access token and refresh token. Is it still possible to use Azure Active Directory B2C in this case? Basically add our own Identity Provider that will refresh the access token when needed. Is this a feasible thing to do and are there any guides in creating this? Perhaps IdentityServer4 could be used or can it be simplified? http://openid.net/developers/certified/#OPLibs https://github.com/IdentityServer/IdentityServer4
Given these words on their website I think it should work:
Support all platforms and open standards
https://azure.microsoft.com/en-us/services/active-directory-b2c/
Yes, it is possible. As Miroslav mentions, you should use custom policies. This requires a ramp up on custom policies which can have a steep learning curve, but essentially you would take the starterpack (see getting started) and you would modify the userjourney to not write to the B2C directory (basically remove this step). Instead, you would do a call out to wherever the users are. This call out can either be an OIDC identity provider or a REST API, which are specified using technical profiles.
I am developing MVC based web application and want to authenticate every users with their own Office365 account. Once signed in successfully, it should provide the details of that user. The users are not specific to my organization only, they can be from any organization.
I have tried below link to achieve the same.
http://graph.microsoft.io/en-us/docs/platform/aspnetmvc
The above link has a very first step to register the application in the azure active directory, but if i will do that then it will only authenticate users from my organization. But in my case, every user has to be authenticated by their own organization.
So i want to know that is it possible? If yes, then how do i achieve that?
Registering you application in your Azure Active Directory does not preclude you from authenticating external users.
With OAUTH you have 3 actors; the Application, the Provider and the User. Each of these actors needs to trust the others. The connection between the Provider and the User is the User Account (i.e. User ID). The connection between the Provider and the Application is the Application Account (i.e. App ID).
When you register your application in Azure Active Directory you are simply establishing an Application ID. The only requirement for the User account is that it also lives within an Azure Active Directory. This does not however have to be the same AAD.
If this is a public facing website, you may want to use the newer v2 endpoint instead. Under the covers it is very similar to the workflow you've been looking at but the registration and permissions process is far more straightforward.
Yes, it is possible you need to enable multi-tenancy on your app. On the app configuration page in the Windows Azure Portal you will find the toggle for "Application is Multi-tenant". For more information about multi-tenant apps: https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/#application-types-and-scenarios
My company wants to develop something it calls a "Login Broker" for an on-premise desktop application also under development. The on-premise application will make significant use of Azure services (DocumentDb, Table Storage, Service Fabric, etc). Our goal is to be able to distribute the main application without it containing any knowledge of configuration values to reach Azure resources (endpoints, keys, etc). As a user logs in through the Login Broker, the desktop application then becomes aware of how to reach its resources, what permissions that user has within the application, and so on.
So far, my research has taken me in the direction of claims-based authentication (I'm very new to this area), which sounds correct in concept. Once a user logs in, the claims that we want to put into a token would be those specifics I mentioned above, plus we will undoubtedly have other claims that we don't know of yet that we want to assert.
My question is, does my company need to develop a custom login service / broker to authenticate users and deliver a configuration payload, or can Azure Active Directory serve this need in the way I described? Is this the kind of thing that AAD is suited for natively or would this wind up being a shoehorn that we'd rather avoid?
What you described looks like the federated identity, locally Microsoft has the Active Directory Federation Services, in cloud there are a few options:
1) Azure AD Access Control Services - https://azure.microsoft.com/en-us/documentation/articles/fundamentals-identity/#ac
2) Azure AD B2C - https://azure.microsoft.com/en-us/services/active-directory-b2c/
I would recommend to take a look at the Azure AD B2C.