My client is selling product in 3 site (US,CA,Mexico) with a same amazon account.
Now he is want using our tool to manage their business in 3 site, first he need to give us the auth token.
So the question is coming:
Does he need authorize to us 3 times in (amazonservices.com, amazonservices.ca, amazonservices.com.mx) or he only need authorize us in amazonservices.com ?
Thanks.
At least in the EU only one authorisation is needed. We can use the same credentials on for example .com, .co.uk or .fr.
Multiple credentials are needed if you are using multiple accounts. With one account, one authorisation is enough.
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 :-)
I would like to make a partner connector for Data Studio with OAuth as authentication method but
I have a little problem as in my case authorization server is different for every user which means that following parameters are unique for every user: AuthorizationBaseUrl, TokenUrl, ClientId, ClientSecret.
Is it possible to make a partner connector with OAuth and make those parameters configurable before starting OAuth?
Thanks a lot :)
Since your AuthorizationBaseUrl is different for each user, the only solution I can think of is to develop your own landing page for each user and use that as AuthorizationBaseUrl. From there, you can collect the correct URL from the user and redirect them as necessary.
Within Azure Active Directory, I have created an App Registration.
For most users, this works great. They can login to my application via federating in from Azure AD, and their claims are coming through.
For some users, however, they have over 150 group memberships in Azure AD. For them, they receive an HTTP 400 bad request. I've increased the maxRequestBytes and maxFieldLength of my server according to this post: https://support.microsoft.com/en-us/help/820129/http-sys-registry-settings-for-windows, but it didn't solve the issue for all users. Some received access after this, but there's a handful that still cannot login.
My application only has ~10 groups in Azure AD that it cares about. I customized my App Registration's manifest to have "groupMembershipClaims": "SecurityGroup".
Is there a way I can restrict the claims coming out of Azure AD to only the 10 groups that I care about?
Per my understanding, this issue is due to too many groups claim in some your Azure AD user access token and you want to limit the group claims.
As far as I know, there is no way to do that. But there will be two workarounds here :
1. this official doc which indicated claims about groups and hasgroups, maybe provides some tips to handle your scenario. As the doc indicated, it suggested you to call an API to fetch all user groups if a user has too many group claims.
In your scenario, you will need to check about 10 groups membership with a user. To avoid the issue that too many group claims in your user's token, you can just remove group claims in token and check groups membership with a user with this API.
2. Using Azure AD app roles claim instead of groups claim. In Azure AD application, we can create Add app roles and assign the role to users or groups. Once be assigned the role , role claim will be added in users' token.
As you only care about 10 groups, you can create corresponding app roles and assign the roles to your groups that you cared about(i,e role1 assign to group1).With this,users in groups will have corresponding role claim(i,e , users in group1 will have a role claim:role1) so that we can use this claim to replace groups claim .
What's more
except for increasing maxRequestBytes and maxFieldLength of your server, you can try to modify maxAllowedContentLength , details see this post .
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
For some time i've been busy building an identity-server, some complicated structures came up as i'm trying to implemented multi-tenancy.
I would like to know if there are any security-risks regarding the approach im planning to take. Maybe others are struggling as well and could use an example-structure. The following case is present:
One identityserver
Multiple tenants with seperate domains
Multiple user-accounts possible for a user per tenant (Student & Teacher)
Registered with multiple tenants under differentusernames/email-addresses
SSO required for all tenants at once
The structure i had in mind:
A user is logged in at the Identityserver. The available clients (applications/tenants) for which de id-server can provide authentication are presented like a hub. One is selected (Company3 for example) and the option to link an account for this specific tenant is available.
The user provides an email (Student#company3.com) and a verification is sent to the user. The identityserver-database holds data regarding a one-to-many relationship between a user and the registered client, and a one-to-many between these registrations and the verified email-addresses.
When logging into the identityserver, the token would hold the data for the tenants and the verified accounts. This token is returned and the current client verifies the token using the key from the discovery-endpoint.
An example of the custom claims would be:
{
"company3":[ "student#company3.com", "teacher#company3.com"]
"company1":[ "student#company1.com", "teacher#company1.com"]
}
Company3 would have secure confirmation that the current user has access to 2 accounts. Company1 would have the same information out the token which makes SSO between the different tenants possible.
As i see it, there wouldnt be any security risks. But, im not very experienced with Identity-servers and authentication yet. I would love some feedback regarding possible security risks.
Cheers