I enabled Cloud Translation API Admin, Cloud Translation API Editor, Cloud Translation API User for principal at https://console.cloud.google.com/iam-admin/ and still getting exception in the code. S
Grpc.Core.RpcException: 'Status(StatusCode="PermissionDenied", Detail="Cloud IAM permission 'cloudtranslate.generalModels.predict' denied. ")'
One thing that I noticed, if I go to Service accounts - Manage permissions - +Grant Access - +Add another Role in select role dropdown I get No matches for "Cloud Translation API" Is this something related?
Is there something that I am missing? Any help appreciated.
Related
I'm working on migrating my EWS app from basic auth to OAuth (app-only authentication).
I created my app in Azure AD and everything works fine.
My only issue is that i don't want my app to have access to e-mails, contacts, etc... I only want to read calendar.
I tried removing "full_access_as_app" and adding "Calendar.Read" permission but i get "401 Unauthorized".
Do you have any solution ?
(image) not working
Thanks
You can't do that with EWS it only supports Full mailbox access via App or Delegate permissions. You can scope the permission so it only has access to certain mailbox using Application polices https://techcommunity.microsoft.com/t5/exchange-team-blog/application-access-policy-support-in-ews/ba-p/2110361. If you want to limit access to just the calendar only then you need to migrate your app to using the Microsoft Graph that supports more constrained authentication.
I'm using the Alexa for Business (A4B) API successfully with an Access Key ID and Secret Access Key with the AlexaForBusinessFullAccess IAM policy. However, I'm interested in building an app that other A4B users can use without embedding their Key ID and Key into my app directly.
Is there any way to create an Alexa for Business app that is authorized using an OAuth flow, like a standard Alexa skill?
I'm specifically looking to sync contacts using various A4B contacts APIs including the following:
CreateContact
DeleteContact
Information on the API is here but I didn't see anything for OAuth here.
https://docs.aws.amazon.com/a4b/latest/APIReference/
https://docs.aws.amazon.com/sdk-for-go/api/
Some information on auth is here:
https://docs.aws.amazon.com/sdk-for-go/api/aws/session/
I'm using Go but appreciate any info.
Just heard from an Amazon rep that OAuth is not available for the Alexa for Business API due to several reasons. The API must be accessed using IAM credentials or delegate IAM permissions.
Currently, a way to do this is to build a configuration page where users can supply their Access Key ID and Secret Access Key in the app configuration from the IAM console with the requisite AlexaForBusinessFullAccess policy.
It may also be possible to have the app enabled using the A4B console and create an IAM role from "Settings" > "AVS permissions" where the user needs to input the "AVS device maker's AWS account ID" and "Amazon ID".
We have an application hosted in GCP which uses GSuite APIs to sync users from GSuite to our application and visa-versa using Service Account. It used to work well until recently some of our customers started facing issues.
We started getting
401 unauthorized. "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
There as been no change in our application and neither in the list of permissions granted. Following are the list of api access granted :-
https://apps-apis.google.com/a/feeds/domain,
https://www.googleapis.com/auth/activity,
https://www.googleapis.com/auth/admin.directory.group,
https://www.googleapis.com/auth/admin.directory.orgunit,
https://www.googleapis.com/auth/admin.directory.user,**
https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/drive,
https://www.googleapis.com/auth/drive.appdata,
https://www.googleapis.com/auth/drive.file,
https://www.googleapis.com/auth/drive.metadata,
https://www.googleapis.com/auth/drive.metadata.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement,
https://www.googleapis.com/auth/admin.directory.device.chromeos.readonly,
https://www.googleapis.com/auth/admin.directory.device.chromeos,
https://www.googleapis.com/auth/drive.apps.readonly,
https://www.googleapis.com/auth/drive.photos.readonly,
https://www.googleapis.com/auth/drive.scripts
The affected GSuite domains were working perfectly until yesterday. Also there are some domains which still work without any problem.
Can somebody please suggest what could the problem be. Is there any change in the APIs recently? Any help will be much appreciated.
"Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
There are several ways to authenticate to Google.
web based applications
native applications
mobile applications
and service accounts
The clients you create for these types is different as is the code to use them. The message you are seeing above means that the code you are using does not match the type of client you have created.
Make sure your code is designed for use with service accounts and make sure that the credentials file you have downloaded from google developer console is in fact credentials for a service accounts.
Why it worked previously and suddenly stopped i cant tell you this is an error you will always get if your code does not match your credential type.
The last option would be to double check that all of those apis are enabled in the Google developer console for your service account project.
I am trying to create Microsoft login authentication service using graph api in spring boot. Not able to find any tutarials for this any suggestions please?
There is a sample to use azure-active-directory-spring-boot-starter package to plugin JWT token filter into Spring Security filter chain.
The sample retrieves user's group membership using Azure AD graph API which requires the registered app to have Access the directory as the signed-in user under Delegated Permissions. You need AAD admin privilege to be able to grant the permission in API ACCESS -> Required permission.
For the details, you could read here. Hope it could help you.
Background
I have a Web API registered in Azure AD and secured using WindowsAzureActiveDirectoryBearerAuthentication (OAuth2 bearer token). This is a B2B-type scenario where there are no interactive users - the applications calling the API are daemon-like background apps. As such, I don't need any consent experience - I just want trusted applications to be able to call the API, and other applications - even if they present a valid OAuth token - to be denied.
What I've tried
This sample seemed to describe my scenario almost exactly. However, the way it determines if a caller is a trusted app or not is by comparing the clientID presented via a claim by the caller to a hard-coded value. Obviously you could store the list of trusted clientIDs externally instead of hardcoding, but it seems like I should be able to accomplish this via configuration in the AAD portal so that a) I don't have to maintain a list of clientIDs, and b) I don't have to write my own authorization logic.
It seems like I should be able to define a permission for my API, grant that permission to each calling app in AAD (or a one-time admin consent), and then in my API just check for the presence of that permission in the scp claim.
From looking at the portal it seems like this is what Application Permissions are intended for:
I can create a permission just fine via the application manifest. Unfortunately, I can't figure out how to specify that it's an Application Permission, not a Delegated Permission! I tried changing the type from User to Admin as described on MSDN, but that seemed to have no effect.
"oauth2Permissions": [
{
...
"type": "Admin",
...
}
Question
Am I correct that Application Permissions are the best solution for my scenario? If so, how do I configure it? Or, as I fear, is this yet another feature that is On The Roadmap™ but not currently functional?
Ben, Application Permissions are declared in the appRoles section of the manifest. Indeed, if you declare an appRole called say 'trusted' in your resource application's (storage broker demo) manifest - it will show up in the Application Permissions drop down there. Then, when you assign that Application Permission to the client app - the access token that the client app will receive using the client credentials OAuth flow will contain a roles claim with value 'trusted'. Other apps in the tenant will also be able to get an access token for your resource app - but they wont have the 'trusted' roles claim. See this blog post for details: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Finally, the above way to assign an application permission to a client app only works when both the resource and client application are declared in the same directory - if however these apps are multi-tenant and a customer will install these apps separately - a global admin from customer's directory will need to consent to the client app - which will result in the application permission getting assigned to the instance of client app in the customer's tenant. (my blog post covers this too)
Hope this helps.
ps: if you're stuck - feel free to ping me on the contact page of http://www.dushyantgill.com/blog