I have been doing some R&D on using the MicrosoftGraphAPI to fetch the skus subscribed by my organization.
I have created an app as described in the documentation. I did all the steps in the above link except 'Assign application to role'.
Using postman am able to get the oauth2 token by sending a post request using the link
https://login.microsoftonline.com/<mytenantid>/oauth2/token
with the client_id, client_secret, resource(https://graph.microsoft.com) and grant_type(client_credentials) parameters.
After this token is obtained I can fire a get request https://graph.microsoft.com/v1.0/subscribedSkus with the Authorization header set as Bearer {token} which will return the SKUs subscribed by my organization.
So far so good. :-)
Now the requirement is I need to fetch the subscribed SKUs by one of the client (let's say having the azure ad tenant id 'ABCDEFG') of my organization.
I can successfully do that by registering an app in the client's tenant 'ABCDEFG' with the same steps as above.
This approach is fine if my organization has say 1 or 2 clients.
However, if the client numbers are more than say 30 this approach of registering an application in each Azure AD instance is not feasible.
If the application that I registered in my organizations AAD was multi-tenant then how should it help me?
What will be the steps needed to obtain the access token for each tenant?
Can somebody assist with some detailed explanation?
Since you need application-level access, you would assign one of the Application permissions listed in the documentation for getting SKUs: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/subscribedsku_list.
Directory.Read.All, Directory.ReadWrite.All
In this case you should require the Read Directory Data (Directory.Read.All) application permission.
Then you mark your app as multi-tenanted.
Now then in order for another org to use your app, they will have to be on-boarded.
You will need some kind of page where their administrator can click a button/link to start using your app.
This should redirect the admin to:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=your-client-id&prompt=admin_consent&response_type=code+id_token&redirect_uri=url-where-to-send-user-back
Once they sign in, they will be presented with a consent screen, where they can approve the permissions that your app requires.
If and when they do that, they will be redirected back to your app (to the URL you specified) and you can use the Id token to know which Azure AD tenant registered.
During this process a service principal for your app is created in their tenant, and the required permission is granted to it.
This means you can then get an access token for their tenant from: (using the same credentials)
https://login.microsoftonline.com/their-tenant-id/oauth2/token
Remember that access tokens are specific to an Azure AD tenant, so you will have to get an access token for each tenant.
One thing I would like to point out is that you should instead try to use delegated permissions if possible.
The application permission given here gives quite large access to your app, and some admins might not use your service for that reason alone.
Delegated permissions are more complex to handle, but allow your app to act on behalf of a user instead of purely as itself.
Related
I have created an app to get various information from Azure AD, such as users and groups. It lives in one of my tenants as an app registration. This works fine, but now I would also like my app to get a list of the ids of other tenants I have in my account.
I have given my app user_impersonation permission on Azure Service Management, and I am able to make
GET https://management.azure.com/tenants?api-version=2016-06-01 requests using my client credentials. However, when I make that call I get a list only containing the tenant that my app/service principal lives in. Is there a way I can use this API call to see other tenant ids from within my app?
Yes, you could do that with auth code flow instead of client credentials flow.
Since you are trying to get the tenants of your account rather than the app/service principal, you have to include the account information when doing the authentication.
Client credentials flow is App-only. Auth code flow is App+user.
See reference here to learn how to implement Authorization code grant (interactive clients).
And here is the document about OAuth 2.0 authorization code flow.
You need to Request an authorization code first and then Request an access token with the code from the previous step. Using this access token, you can list the tenants you have in your account.
As shown by many samples I have two AAD application registrations, one for my javascript-based front end, and one for my JSON-only web APIs.
If I fully trust my client AAD application, why does AAD require me to create a second AAD application for my web APIs?
For example, assuming I add specific roles to my client AAD application, if client signs in with AAD and gets an id token and access token containing my roles, it only needs to send the access token to my APIs. The API only needs to crack the JWT, validate the audience, issuer, tenant, roles permissions, and signature. In this world, no client secret is needed in the web APIs, a second AAD application registration not needed, and still no call to AAD from my APIs. Unfortunately, without two AAD applications, I cannot figure out a way to have AAD include roles into my access token.
If I didn't fully trust the issuer from mucking with claims, I can see why I would need two AAD applications and a client secret. But since I do trust my AAD application and the signature of the JWT, why the extra complexity? Or maybe there is a way to do this that I haven't found?
Thanks!
Responding to Marc here because just not enough characters in the comments field -- The sample you referenced is an excellent sample, specifically the JavaScript one calling the Web API. It is what I am doing right now in fact. However, the problem is that Web API in the sample is open to anybody who has authenticated on the tenant. I need to secure the Web API down to certain individuals in the tenant, and simply checking the client/app id is not sufficient as anybody who can create an AAD app can fake it.
So what I need to do is have roles added to the the access token so I know that my application authenticated the user, and that user has been granted the required roles. For example, here is a Microsoft sample. And even here a Microsoft video walking through the process.
If I don't have two AAD applications w/client secret, the roles claims is never provided in the access token. It is always provided in the id token, but not the access token.
I feel like I am missing something obvious here. If AAD would just put the roles I requested into the JWT when I authenticated against it, and I validated its signature, audience, issuer, and roles, I wouldn't need any of this extra complexity?
Ah, I think I understand where you are going: you would like to control which users can access an API, no matter what client app they are using to access the API with. That's a function of the API - you cannot control that through AAD. In AAD you can control which users can access which applications (UI) using either user access restrictions (enterprise tab) or role-based access. However, access to an API is controlled in AAD at the calling application level via scopes. APIs are never accessed directly by users but only by other apps so controlling access permissions at user level would cause admin havoc. So, you can control what permissions a user has in the app they are using and you can control what permissions that application (client) has in other applications (APIs, resource servers) it is using.
In other words: role is about user access to UI, scope is about one apps' access to another.
App secrets provide added security for getting tokens - they have no bearing on what permissions are included in the token.
Can you provide a link showing that two apps are needed? That should only be the case if the API you want to call is not provided by the web app which served the JS to the browser. None of the 'official' samples require you to register two apps (Graph API, used in some of these samples is a separate API and it is already registered). A problem with tokens passed from the browser is that they were acquired by a public client, not using any secrets apart from user creds. Therefore, they are easier to steal and re-use. Your own back-end app may want to use a secret to get its own token (extension grant) to call yet another API using a token that does not reside in a public client.
I am doing login from Azure AD.Client is SPA(angular using MSAL). If user is not Authenticated, it redirect to Microsoft Login Screen (using MSAL). On successful login, it return an access token.
My roles will be stored in a database. I need to add the roles of that user as part of claim in access token. I am not finding the way to do it.
I do not want to make another call from SPA to API to get the DB roles.
Please suggest some good approach.
Any links explaining the approach will also be very helpful.
I am still in design phase but not able to find the best approach.
In one microsoft site, i found that we can fetch the roles from DB but details were not there.
most of the places, it is written that we need to provide roles in Azure AD users menifest file.
In regular Azure AD, the "roles" claim is exclusively sourced from app role assignments for the signed-in user (or groups the user is a member of), to the app roles for the app the user is signing in to.
There's no feature currently in Azure AD which will connect to an arbitrary database, make a database query in the appropriate form, and include the results in the roles claim in the resulting ID Token.
I can think of three options to achieve your scenario:
After sign-in, call an API to retrieve the roles. Though you mention this is not desirable, it's probably the simplest approach, so it's worth listing. As a result of the user's sign-to you app, you app will usually obtain an access token to an API. If you set up your API to be secured with Azure AD (directly, or through Azure API Management), your SPA could simply get the necessary access token as part of sign-in, and at that point it's trivial to make a REST call to retrieve the role details for the user (and possibly other information useful to rendering your app).
Synchronize (or copy) your role information from your database to Azure AD. For each role, create an app role in the Azure AD app registration. For each user-role association, either create an app role assignment to directly assign the user (user -> app role), or assign a group to the app role and add the user to the group (user -> group -> app role. Keeping this in sync is probably not trivial, so if your scenario allow to move the role information to Azure AD app role assignment, you can forget the database entirely (making Azure AD the authoritative location). Of course, this might not work for your specific case.
Use Azure AD B2C and a custom sign-in policy. You could create an Azure AD B2C tenant, set up a custom sign-in policy to use your (regular) Azure AD tenant as the identity provider, and configure the policy to enhance the claims by calling a REST API to retrieve your roles. In this approach, you still need to have a REST API which can provide the role information, so rather than doing the setup and migrating your app, you may prefer simply calling the API from your SPA (option 1, in this list).
I'm getting 403 forbidden access when trying to fetch all the groups from Microsoft graph using ASP.NET Web API, and here is my code to get all the groups:
String jsonResponse = MicrosoftGraphHelper.MakeGetRequestForString (
String.Format("{0}users/{1}/memberOf",
MicrosoftGraphHelper.MicrosoftGraphV1BaseUri,
upn));
var userGroups = JsonConvert.Deser
What are the required permissions in both Delegated and Application tabs for fetching both users and groups? Do I need Application permissions since this is an API and my UI is deployed in azure separately? I'm confused with the list of permission options and with admin consents.
Firstly, here's a great read in case you haven't seen it yet.
Delegated permissions, Application permissions, and effective permissions - Microsoft Graph permissions reference.
What are the required permissions in both Delegated and Application tabs for fetching both users and groups?
You can understand the required permissions for each api by looking at relevant documentation. With the information you've shared in your question..
For users/{1}/memberOf it will be List memberOf
For getting all groups - List Groups
If it's just these two calls in your application, Directory.Read.All would be the least privilege required. In case there are other calls, look at their documentation.
Do I need Application permissions since this is an API and my UI is deployed in azure separately?
This will depend on whose context do you acquire the token to call Microsoft Graph API. Share a little more information on your code.. OAuth flow you use to acquire token and you might get better suggestions specific to your application. In general though,
If you acquire the token as a user, then Delegated permissions (Example if you acquire token by prompting the user for credentials and from a flow perspective if you're using say Authorization code or Implict grant flow)
If you acquire the token as an application, then Application permissions (Example if you use only clientId, clientSecret/certificate to acquire token using Client Credentials flow)
Admin Consent is required or not?
This depends on what permissions you finally end up deciding as required for your application.
You can see it directly in Azure portal.. when setting required permissions fro your application, each permission has a yes or no next to it to indicate whether Admin consent is required or not. Just as example see screenshot below.
Microsoft Graph Permissions Reference.. the first link I had shared has all permissions documented. Example here is one that is relevant for you.
We have a multi-tenant Saas application providing sign in using our username/pwd authentication system and using Azure AD (OAuth 2.0 flows). When a user signs in using Azure AD, we can get the user's profile using https://graph.windows.net/{tenantid}/me. We want however to get more information using the memberOf or getMemberGroups operations to retrieve the user's groups in the tenants directory, to map specific groups from the tenant to an organizational structure in our application. However these operations always fail with a Forbidden statuscode. Are we missing required permissions or is it just not possible to query for the groups and roles of another tenant.
Thanks in advance
This is totally possible, but today requires that you request the "Read Directory" permission. This permission does require and admin of the tenant to consent. We are looking at adding some additional fine grained permissions for Graph API that will allow users to consent (to get group membership information).
Another option for you is to configure your application to request group membership claims (which should appear in any user or JWT token). You can do this by going to the azure management portal and getting to your app's config page. From there download the application manifest file and update the groupMembershipClaims property. You can see most of the properties in the application manifest described here: https://msdn.microsoft.com/en-us/library/azure/dn151677.aspx. Once updated, you can upload this app manifest file, and this will configure your application accordingly. Once done, AAD will issue group membership claims in the token. Dushyant has written a nice blog about authorizing access to a web app, using group membership claims or app roles. You can find it via Alex Simons blog post here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
HTHs