I have a service that will be registered in Azure AD as an App. It will have one app registration per region (West US, East US, etc.). Clients calling this service need to acquire an access token. The audience of the access token MUST be the corresponding service for the region. The services are segregated regionally so that an access token for a service in one region cannot be used to access the service in another region. This is by design.
Is there a proper way/recommended best practice for the application discovery?
I have explored the idea of using Graph API. In the model:
Each of the registered services will be created using a templatized naming convention e.g. -. There is a concern here that without proper coordination within the tenant where these apps are being registered, we could end up with a name collision.
A “discovery app” (application registered for the sole purpose of usage for discovery) will have Application.Read permission the Graph API. Authentication here will be based on a X509 certificate for greater security.
Using an access token acquired against the discovery app, Client will query Graph API for the intended service app audience matching on the name. Once that app info is obtained, we’ll have the service app id. Again, concern from #1 above still stands - another application registered with same name will also be found.
Client will then use service app id obtained to acquire an access token to talk to the service.
Any help/direction would be much appreciated. Want to make sure I am not re-inventing the wheel if there is already an appropriate pattern to doing this.
Your design is feasible. Of course, you need to make reasonable adjustments to the names of app registrations to eliminate the influence of name collision.
I have a suggestion that you could add these service app registrations into a security group and use Microsoft Graph (Beta version) to list them with a filter (templatized naming convention).
Reference here:
GET https://graph.microsoft.com/beta/groups/{id}/members?$count=true&$filter=startswith(displayName, 'a')
ConsistencyLevel: eventual
Please note that $count=true and request header ConsistencyLevel: eventual is necessary.
There is a property appId in the response which is what you need. In this way, the influence of name collision can be avoided as much as possible.
Related
My company owns several (verified) facilities and using my company's email i can see those locations (business.google.com).
Now, my company would like to fetch the reviews in each location and present it in our company website. Before we're using the Google Place API but since it only returns the latest 5 reviews we opt to using Google My Business API to retrieve a location's complete reviews. We'd like our backend (PHP) to retrieve the reviews so using the same email I created a service account (console.developers.google.com/apis/credentials) because we don't need the end user to allow/interact anything when browsing our website.
Using postman (with my signed JWT) I have managed to get a valid access token
...that I use to retrieve the lists of accounts (mybusinessaccountmanagement.googleapis.com/v1/accounts) I could see the service account itself alone in the response.
Now, I tried calling the account locations api (mybusiness.googleapis.com/v4/accounts/{MY_ACCOUNT_ID_HERE}/locations) but it only returns and empty object response.
Can someone help me resolve this issue. Why my service account can't see the verified locations under my company's email. Is this even possible? Thank you.
Even that this is an older question - I run into the same issue calling the new Google My Business Information v1 API (getting empty results) using a service account.
It seems, that it is not recommended to use Service Accounts, I found this support article on Google: https://support.google.com/business/thread/8281160/cannot-get-access-to-gmb-locations-with-service-account-with-nodejs?hl=en
The "official" recommendation is to use OAuth.
But we finally made it using Service Account. The following steps are necessary to resolve it (at least for us it is working now):
Add a project in Google Cloud Platform
Add and enable the Account Management and Business Information API's.
Add the service account and generate a key (https://developers.google.com/identity/protocols/oauth2/service-account#creatinganaccount)
Make the Business Profile API request (you need the approval made by Google to be able to make requests against the two API's; otherwise you may run into quota exceeds as "Request per minute" is set to 0 by default). Important: It may take up to 2 weeks until, but we received the approval within about 5 days
Enable domain-wide delegation for the service account using the scope "https://www.googleapis.com/auth/business.manage". More about domain-wide-delegation: https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority)
Add a user identity in GCP. This user also needs to be added in Google My Business for editing locations. When creating your ServiceAccountCredential object, impersonate this user.
Security concerns:
Domain-wide-delegation enables that everyone knowing/having the credentials of the service account could impersonate any person (identity) from withing GCP. At least in this case only for Business Profile API, but anyway, keep this in mind.
Also using private keys for authenticating the service account is not recommended, you should be aware to regularly change / create a new private key or there would be a solution with Identity Workload.
Hope this helps everyone facing the challenge with GMB / GCP / service accounts :-)
We are evaluating an option if the "same" azure AAD access token be used to access multiple webapis.
Here is the flow :
Client -> webapi1 -> webapi2
1) client authenticates against AAD and acquires token1 <br>
2) client calls webapi1 with token1<br>
3) webapi1 calls webapi2 with token1
Lets say both the webapi's are configured to validate the same audience ('xxxx') and authority, are there any complications/security issue to leverage the same token for both the apis.
Any input is much appreciated.
In that case webapi1 and webapi2 are essentially the same API as far as Azure AD is concerned.
One con of this approach is possibly too many privileges on the APIs.
Let's say API A requires access to all users' emails in the organization. Now since API B is effectively the same app from AAD's point of view, it also gets this right, though it didn't need it.
Typically we try to follow the principle of least privilege, where every part of the app has exactly the access it needs, and no more. So using the same audience again can go against this.
Another issue is that another app which has rights to call API A also gets rights to call API B.
I can understand your reasoning for avoiding the round trip of fetching an additional token, but tokens can be cached.
Our application (referred to as "XYZ_App" below) is a multi-tenant SaaS application. We are in the process of making it available for Microsoft AppSource as a multi-tenanted "Web app / API" (referred to as "AppSourceXYZ_App" below).
We started our OpenID Connect implementation with endpoints pointing to “common” as per stated in the documentation when multi-tenancy is desired/required.
In XYZ_App, we added information in the system to know what AAD instance each XYZ_App tenant is associated with (using the GUID Microsoft assigned to this AAD instance, we are NOT using the "rename-safe.onmicrosoft.com" representation).
When using the “common” endpoints, we had to manually validate the issuer from the JWT to make sure it was the expected one: a user could access XYZ_App requesting access to XYZ_App’s tenant associated with contoso.onmicrosoft.com, get directed to “login.microsoftonline.com/common” to authenticate and then decide to authenticate with a user from another AAD instance (referred to as "anotherAADInstance.onmicrosoft.com" below). In this scenario, even though a user could successfully authenticate on anotherAADInstance.onmicrosoft.com, XYZ_App’s redirect URI must make sure the JWT issuer is the one from contoso.onmicrosoft.com. I’ll refer to this setup as Scenario_1.
With that scenario in mind, we thought about NOT using “common” and customize the requests going to login.microsoftonline.com on the fly; attempting to “jail” requests to be forced to authenticate against a specific AAD instance. We would still need to perform our validation in the redirect URI to make sure the issuer is the appropriate one, but we thought this approach might make our lives easier. I’ll refer to this setup as Scenario_2.
Do you envision Scenario_2 is viable in the long run or is it too short-sighted ? Based on my current knowledge of OpenID Connect, one limitation I can see with Scenario_2 is that it would become problematic to support “broker accounts” into our app.
Explanation of “broker accounts”: in our industry, some external users are allowed access to the system. Let’s say I have a company called “BrokerCo” (with their own brokerco.onmicrosoft.com AAD instance) who has 2 employees: Broker1 and Broker2. BOTH anotherAADInstance and contoso hired Broker1 and Broker2 to get broker services to perform tasks in XYZ_App; requiring XYZApp to grant them access. What is the ideal way for authentication from an OpenID Connect standpoint ? If XYZ_App were to use “login.microsoftonline.com/common” for authentication (like in Scenario_1; as opposed to “jailed” access like in Scenario_2), Broker1 and Broker2 could authenticate with brokerco.onmicrosoft.com (no AAD "External users" for anotherAADInstance nor contoso), but they would then get to redirect URI with an issuer that is different than what XYZ_App’s anotherAADInstance and contoso tenants are configured for... I feel like I’m back to square 1...
Do you have suggestions or pointers to solve this issue ?
Background context:
While playing with OpenID Connect issuers, I got the following error message:
AADSTS50020: User account 'testuser#anotherAADInstance.onmicrosoft.com' from identity provider 'https://sts.windows.net/XXXXXXXX-fake-GUID-9bZZ-XXXXxxxxXXXX/' does not exist in tenant 'XYZ Publisher' and cannot access the application 'YYYYYYYY-fake0-GUID-YYYYyyyyYYYY' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
Thanks in advance !
Your question has multiple layers, trying to address most of them:
AppSource is about trial experiences for new users: this mean that any corporate account around the globe can potentially be an user of your SaaS application - or at least to the trial experience of your application, therefore the first thing you need to think when integrating with AppSource is how easy it has to be for a potential user to experience your app for the first time.
With that in mind, AppSource recommends that the trial of application is build on such a way that allows any user from any organization to sign-in, and therefore a multi-tenant approach for your application is the recommended setup for any application.
The single-tenant approach requires more control on your side, and for a trial experience - it means that the user cannot try your application right away because the operation you have to do on your single-tenant application is to add the user to an Azure Active Directory tenant as a guest user. This guest account will need then to wait receiving an email to accept the invitation to join to this tenant you are adding the user to then sign-in to your application.
Therefore your scenario 1 is the best scenario thinking on a trial experience in general, and also in general require less management (as you'd not need to create/ manage each individual account that needs to access your application as guest users of your Azure AD instance).
However some concerns you listed - that this scenario bringing are valid: Because you are accepting the common endpoint, you are saying basically that any user can sign-in to any tenant to your application, and this may not be desirable. In addition, the scenario you listed that a user can generate a token for any application is also valid, however, you can add additional checks to make this more secure and that any token generated by another authentication is blocked:
You can validate the 'audience' claim to guarantee that the token was issued to your application
You can eventually check the 'tid'/'iss' claims against of a list of tenant Ids in your database to see if that the user's organization is a valid organization in your application -- this would be valid for non-trial users/ organizations.
More information in this article.
About scenario '2' and broker accounts:
This scenario could be interpreted in two different ways:
Broker accounts are guest accounts of a customers' Azure AD tenant
Broker accounts are third party accounts but are not actually added as a user of anotherAADInstance or contoso AD
If your case is '1' then you're right: if your application needs to authenticate guest users that belong to another Azure AD tenant, then common endpoint could not be used directly.
If your case is '2' then what you'd need to do is to continue using the common endpoint and somewhat after the user is authenticated ask them to choose the company. I am describing this on generic terms without fully understanding this scenario. Perhaps this is not simple as you want the remote company to control this and not the user - so some additional complexities may need to be handled here.
A note is that if your scenario is scenario 1. - in theory - you can still use an hybrid approach, where you'd ask user to type the username inside the application and the company that they want to sign-in, then check if you need to validate the user against common or tenant-id endpoint, preparing the request and then sending a login_hint argument when authenticating. More information here
Our current process is BizTalk expose a web service for vendor to call in, where the request header contains pre-assigned user name and password. Upon receiving service call, BizTalk validates the credential against the database, extract and attach some metadata from db record to the inbound message (e.g. city, vendor level etc)
Question,
can we replace this process with Azure Active Directory? Heard it does provide a restful API, but get confused everytime reading the documentation when talk about JWT token... Does it have a straight forward restful endpoint to call to validate and extract user information?
can we customize the metadata within the AAD user?
Thanks for the help!!
1 - sure you can. There is no endpoint to perform validation, but it's easy to validate incoming tokens - we offer components that automate it. See https://github.com/AzureADSamples/NativeClient-DotNet for an example. The same location on guthub has lots of other samples demonstrating different scenarios.
2 - I am not certain I understand what you mean with metadata here. If you are referring to the info you can specify about the user: you can customize the user scheme. See https://msdn.microsoft.com/en-us/library/azure/dn720459.aspx
I've got AngularJS and Web.API WAAD authentication up and running. For client side I use great library ADAL.JS. For backend I use Microsoft.Owin.Security.OAuth. This part went quite smooth.
Now I want to implement authorization based on roles (which will be mapped to WAAD groups). Groups are not included in authentication token so I must ask Azure Graph API for them. I saw various ways to do it, using custom claims providers, adding web services to project, etc. Some examples already providing mapping between groups and roles to use in [Authorize] attribute.
But what is just the simplest example of how to get a list of group ids/names from WAAD providing User ID or username, when I'm already authenticated?
Also, is there any way to get this data in JS to use in Angular frontend, or should I create an API service which Angular should call for roles info?
In the non-JS case, the simplest way of getting groups in the token is by opting in. Download your application’s manifest, locate the “groupMembershipClaims” entry, change its value to “SecurityGroup” or “All”, upload back the manifest.
However note that this won't work for your scenario, because it uses the implicit grant - here the token is returned in an URI fragment, hence a big token would risk blowing past the URL length limits of the browser.
You can always request groups to the Graph and make it available to your frontend via custom action on your API, but from what you wrote you are already familiar with that. Let me discuss the matter here - if there's a simpler route to make this work in SPAs, I'll get back to this thread.
HTH
V.
Update: I verified and in the implicit grant case you will receive groups always via the overage claim. Please refer to https://github.com/AzureADSamples/WebApp-GroupClaims-DotNet/tree/master/WebApp-GroupClaims-DotNet - it will show you how to process the overage claim to retrieve groups. All you need to do is apply the same guidance to a web API instead, and if you need to make the info available to the client expose one or more actions doing so.