I want to use Drive & Sheets API from Python3.
I tried to create a service account in GCP console, but it said You already have credentials that are suitable for this purpose, without telling me what role of GCP makes it suitable.
Now I want to find and add the role to my favorite service account. I do not want to create a new one, nor use the already-suitable ones.
What is the name of the role which allows using Google APIs?
I think this is confusing and poorly explained in Google's documentation but IAM and OAuth scopes are mostly (now) complementary technologies. I consider IAM to refine or provide more granular, account|credential-specific scopes
Scopes came first and IAM came later.
IAM -- actually Cloud IAM -- applies only to Google Cloud Platform (GCP) services.
OAuth scopes exist for all Google's APIs (including those of GCP).
https://developers.google.com/identity/protocols/googlescopes
In your case, Drive and Sheets are part of G Suite and not included in Cloud IAM. There are thus no IAM roles for you to assign to your service account that apply to these services.
For GCP services, it is customary (though seemingly redundant) to use both IAM and scopes.
Often you'll see https://www.googleapis.com/auth/cloud-platform used as something of a catch-all|default scope.
UPDATE: In retrospect, I should add a qualifier to this, OAuth scopes are effectively redundant for service accounts. In the case of a human|user-based OAuth flow where the end-user is delegating authority, the scopes remain relevant as they summarize the permissions for the end-user to review before granting to the code.
Related
Background:
I have 2 services, A and B, both requiring access to service X, all running on Cloud Run.
Service X requires authentication, since both A and B have their own service accounts, I gave them the invoker role on service X, made sure access tokens are set on headers, so everything works.
Actual question:
I want to restrict access to specific APIs within service X. Ex: I want Service A to be able to only use READ endpoints, but B to be able to also use WRITE endpoints.
Is there any way to include custom scopes or claims to access tokens generated by GCP from service accounts so I can have granular access control at the API level?
Note: I come from an Azure background, where we could setup and API with scopes, and assign those scopes to accounts. Trying to understand if there's an equivalent on GCP.
In gcp we can create a custom role service account while calling API, In your case you need to create 2 service account with custom role, one with viewer role and other with writer or editor role.
Here is a blog explaining the process of creating a service account with custom roles.
While calling an API make sure you are using the correct service accounts for performing read and write operations respectively.
some questions about service accounts and best practises on GCP.
1) I'm able to create a "brand new" service account. How can I ensure that this new service account doesn't have any kind of privileges bound to it? I'm asking this because for a project I need to create multiple service accounts with only one permission: write access to a single Google Storage bucket. Nothing more. How can I ensure that this is the only granted permission and nothing else ?
2) Should I create a new Google Cloud Project for every customer I have, in example, one project for each website that I'll host to GCP or a single company project (in this case, my company) would be enough to hold all Compute Instances, Storage buckets and so on, needed by my customers ?
Managing hundreds of project would be overkill, if possible, i prefere to avoid this, without impacting secutiry.
Thank you.
You can only constrain service account permissions to enabled services that implement IAM (the Google Cloud Platform services including Cloud Storage). For services that don't implement IAM, the only way to limit a service account's auth is through OAuth scopes.
Projects appear provide a more robust security perimeter for you to separate your tenant customers. Additionally, you get enforced separation of billing, logging, auditing etc. It's debatable whether managing per customer projects (each owning a bucket and related service accounts) has different security than a multi-customer project (with many buckets and service accounts) since service accounts may be easily extended across projects. I recommend whichever path you choose, you ensure control is effected programmatically to minimize human error of granting one customer's account(s) to another customer's bucket(s).
HTH!
I'm working on a service that provides smart (hopefully) integration of different services supporting OAuth 2.0. The focus of our tool is on team work flow improvement, so we're combining Slack, GitHub, Asana (issue tracker), Cezanne (hr tool), etc.
We have ui and backend that work with all those tools (user is authorised to all of them, so I have required access and refresh tokens). We need to be able to hide different parts of the ui depending on person's role in a specific tool. Let's take GitHub as an example. The user can be a repository owner, contributor, company owner (for business account), etc, so those user might need different ui based on their rights.
Originally I was hesitant implementing authorisation on my own (another custom authorisation system is the last thing this world needs), I wanted to take advantage of other services' authorisation mechanisms and just create a lightweight wrapper around them. It seemed like a reasonable idea at first, but I can't figure out how to implement it and Google doesn't give valuable advice which means: 99.99% I'm trying to do something stupid, 00.01% I'm trying to do something rare/innovative.
I hoped to take advantage of OAuth 2.0 but it doesn't seem to support what we need. The closest thing is scopes but it doesn't look very relevant to our scenario.
The only idea I have for now is to create our own authorisation system and integrate other services using kind of reverse engineering. So I would request user's GitHub account details using API and apply him roles in our system appropriately: Owner for repository A, contributor for repository B, owner of company C, etc. I will have to reverse-engineer the permission for each role (i. e. repository owner can not change company name). And we would have to keep user roles for each service: so instead of typical Admin/User/Manager/etc. we will get: OwnerOfGitHubRepository (for repositoryA), ManagerOfAsanaTeam (for team B), etc.
It would be awesome if OAuth 2.0 services had an endpoint that would return the permissions available for a current user.
I'm not a security engineer, so I might be missing something obvious. So wanted to ask you guys for advice before investing into the implementation mentioned above.
The word, "authorization", is used in two different contexts.
In one context, authorization means "who has what permissions". Solutions for this authorization is "identity management".
In the other context, authorization means "who grants what permissions to whom". Solutions for this authorization is "OAuth".
In some cases, you may have to handle these two authorizations simultaneously. See this question and this answer for details.
You tagged your question with identityserver4.
This Issue for identityserver3 from last year may interest you.
But I'm afraid most providers don't support this oauth2 profile (yet).
UMA seems to be an oauth2 way to enable fine grained authorization, but may not be the best solution.
Since Graph is a self-documenting language, I wanted to use this to my advantage and write PowerShell functions to automatically generate cmdlets based on metadata. I've got a lot of this complete, but am having problems figuring out scopes. Is there a way to find scopes? It's not stored in the metadata and the documentation doesn't have scopes listed for everything (for instance, nothing in Excel has scopes listed).
The Graph Explorer seems to request correct permissions, so that has access to this list somewhere.
It depends on which API you are looking for.
Scopes for Azure AD Graph API is at https://msdn.microsoft.com/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes.
There is a huge list for different parts of the Microsoft Graph API at https://developer.microsoft.com/en-us/graph/docs/authorization/permission_scopes.
When you first sign in to Graph Explorer, you give it these permissions:
Based on the descriptions and the link above you can figure out what the scope name is for each of the items in the list. (E.g. the first one is Mail.ReadWrite).
When you create an application in Azure AD, you configure which applications it needs access to, and what access it needs. That results in the list which the user grants access to on first signin.
I setup and MVC 4 application and added authentication against our Azure AD server as outlined here: http://msdn.microsoft.com/en-us/library/windowsazure/dn151790.aspx
Authentication works as expected. However, I'm not getting any roles back by default. There should be several AD groups created and I would like to use them to role restrict the application via the [Authorize] attribute in MVC.
I can't really find a good place to even start figuring this out. Can anyone give me an outline or point me to a good tutorial?
I should mention that I'm not the administrator for our Azure account, so I need to be able to tell our admin what to do if any setup is required on that side.
First, tokens returned by Azure AD do not currently contain claims for roles or groups, so you need to get them from the Graph API. Second, roles in Azure AD that are returned by the Graph API are not necessarily intended for use in an ISV/LoB app, and in general you should use security groups for authorization instead. To perform authorization, you should use the checkMemberGroups or getMemberGroups operations in the Graph API, which are transitive and valid for this purpose.
If you check out the following resources in order, I think your questions will be answered. You'll learn how to authenticate to the Graph, call it, and configure your application to use the result of the group operations to perform authorization:
Using the Graph API to Query Windows Azure AD -- This is the second walkthrough to complete now that you've done the web SSO one.
Authorization with Windows Azure Active Directory
MVC Sample App for Azure AD Graph
Blog post describing checkMemberGroups and getMemberGroups
How do I get role and group membership claims for users signing in via Windows Azure AD? -- This one is out of date in regards to the methodology for authentication and the UI for managing users/groups, but it's still useful. Pay special attention to the section on the custom ClaimsAuthenticationManager, which gives you an idea of how to inject role/group data into the ClaimsPrincipal object early so that it can be used in the [Authorize] attribute or other authorization logic.
Sean answer is a bit outdated. You can now configure Azure AD so it will include groups or roles inside JWT token so it will be included into ClaimsPrincipal.Current.Claims so standard [Authorize(Roles = "yourRoleName")] attribute will work.
Here is introduction post. Which basically says you have two options:
Use groups claim - you need to change groupMembershipClaims value in app manifest and later in application you can check for ClaimsPrincipal.Current.FindFirst("groups").Value to see in what group user is (you only get group id). You can write you own Authorize attribute that use this. more info
Define roles for you application and then use normal code for testing if user is in role:
[PrincipalPermission(SecurityAction.Demand, Role = “yourRoleName”)]
[Authorize(Roles = “yourRoleName”)]
if (ClaimsPrincipal.Current.IsInRole(“yourRoleName”)) { //do something }
You need to edit roles in you app's manifest.
More info here and here. Values needed to be set in manifest are described here
What is really strange is that you can't assign more than one role to group from Azure web page. You need to use azure graph api for this.
If you can't see Users and Groups tab in Azure portal you probably need Azure AD Basic or Premium edition. If you are working on free azure subscription you can use free Azure AD Premium trial to test stuff.