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.
Related
I am working on service to service authentication using the client credentials flow.
I am using keycloak as the authorization server.
Let's say, there are two services S1 and S2.
Every service will allow only certain other services to call its APIs. It might also happen that two different APIs of one service might permit different set of callers.
I have created roles. I have created scopes and mapped the roles to the scope.
When I am passing the scope in the get token call (/realms/realm_name/protocol/openid-connect/token), I am getting the token with roles that are mapped to the passed scope.
What I am not able to figure out is how do I restrict the assignment of different roles to different services?
Only service owner or admin should be able to login to keycloak and should be able to assign the roles corresponding to his/her service to other services. He should not be able to do anything with roles not meant for his service.
Eg:
S1 has owner O1 (a user in keycloak). S1 has three APIs A1, A2 and A3. To call A1 API, caller should have R1 role, and to call A2 API, caller should have R2 role.
Now if service S2 wants to call S1's API A1, only admin or user O1 should be able to attach role R1 to S2's client in keycloak (or add role R1 to scope attached to service client S2).
This might be related to limited access to perform different operations in keycloak.
If I understood your request correctly you can try to use client finer permission. Run keycloak with the following flag:
-Dkeycloak.profile.feature.admin_fine_grained_authz=enabled
Then in your client you can choose which user can do what with the client:
For example, you can client on the permission view and then create a policy based on the user, and then configure the rest accordingly.
You can in the Keycloak official documentation read more about Managing policies.
I am working on a service that logs into JIRA and performs few operations that are not associated with a particular user. Right now, I'm using a virtual account and authenticating the JIRA by the accounts username and password. The use case requires a significant number of such services to be created. The current solution will be messy to maintain, because I need to keep a track of service level logs, which will require creation of a large number of virtual accounts, whose management is difficult. Is there a service account like concept in JIRA that allows a service to perform authentication as an application like on Google cloud?
Their reference about the REST API.
I played with it once, remember it requires API key or token maybe.
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.
I am developing a python app running on embedded linux to access office365 calendar via the EWS interface. I plan on using impersonation to access data.
I have registered my app with azure AD and retrieved the endpoints which contain a tenant id. But I have learned that using the common endpoint seems to work just fine in refreshing the access token.
what are the advantages or limitations in using the tenant id instead of just using common?
Take a look at http://www.cloudidentity.com/blog/2014/08/26/the-common-endpoint-walks-like-a-tenant-talks-like-a-tenant-but-is-not-a-tenant/. The common endpoint does late binding to the tenant based on the users login details. The article does add "For line of business applications you do NOT want to late bind the tenant, in fact you want to ensure that the caller comes from your specific tenant and no other! In that case, use of common is not appropriate."
I am developing a Web API that talks to Azure AD Graph to get and update user and group information. So I have implemented a service application/service principal according to the article at https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet, using Windows PowerShell.
I now want to add some custom attributes to my application so that groups can have extra fields. However I can only see it in the Azure Portal when I refer to it by its specific application id and also I can't get to it using the AD Graph RESTful API at https://graph.windows.net/{mytenant}.onmicrosoft.com/applications or /{mytenant}.onmicrosoft.com/applications/{objectId}/extensionProperties and thus can't add any new custom attributes by using the corresponding POST endpoint.
Comparing my service application with other enterprise applications in my tenant, it also doesn't have a publisher showing in the enterprise applications blade.
Please can anyone advise whether this is supposed to work, and if so what am I missing by way of configuration?
thanks
Simon
The issue you are seeing here is due to the fact that the tutorial you followed had you create a Service Principal using AAD PowerShell, however the properties you are looking for are on the Application Object.
You can read more about the differences here.
Application object
An Azure AD application is defined by its one and only application
object, which resides in the Azure AD tenant where the application was
registered, known as the application's "home" tenant. The application
object provides identity-related information for an application, and
is the template from which its corresponding service principal
object(s) are derived for use at run-time.
Consider the application object as the global representation of your
application (for use across all tenants), and the service principal as
the local representation (for use in a specific tenant). The Azure AD
Graph Application entity defines the schema for an application object.
An application object therefore has a 1:1 relationship with the
software application, and a 1:n relationship with its corresponding n
service principal object(s).
Service principal object
The service principal object defines the policy and permissions for an
application, providing the basis for a security principal to represent
the application when accessing resources at run-time. The Azure AD
Graph ServicePrincipal entity defines the schema for a service
principal object.
Before an Azure AD tenant will allow an application to access the
resources it is securing, a service principal must be created in the
given tenant. The service principal provides the basis for Azure AD to
secure the application's access to resources owned by users from that
tenant. A single-tenant application will have only one service
principal (in its home tenant). A multi-tenant Web application will
also have a service principal in each tenant where an administrator or
user(s) from that tenant have given consent, allowing it to access
their resources. Following consent, the service principal object will
be consulted for future authorization requests.
My suggestion is to use the Graph API/Portal UX/PowerShell to create an Application Object first, and then follow the tutorial by updating the service principal of the application you created.
Let me know if this helps!