Is there a way to create a service account in the context of Google's cloud services that can only access BigQuery and not any other service (GCE, App Engine, &c)? Or is it necessary to create a new "project" and put the account in that project?
There are two ways to scope access:
ACLs and group membership allow control over what the service account has access to.
OAuth credentials can be scoped to individual services / apis.
Either option could work for you, depending on what your ultimate goal is.
How to use ACLs to limit access to only BigQuery
A service account is an identity, just like an email address is an identity.
Identity access is controlled through ACLs, either on the project or on the individual datasets you want to manage. BigQuery's access control is described here: https://cloud.google.com/bigquery/access-control. Other services and apis offer their own ACL controls. Together, these options give you fine grained control over access.
For example, if you put the service account in the project owners ACL, then that service account will have access to everything a project owner would have: BigQuery, Google Storage, etc.
Alternatively, if you put that service account only on a single BigQuery Dataset, then it would only have access to that dataset. (If you also want that service account to be able to run BigQuery jobs, then it would need to be a member of some project since jobs run in the context of a project. If you have a requirement that the project you run BigQuery jobs in cannot be the same project that you store Google Storage data in, then you will need multiple projects.)
How to use OAuth Scopes to limit access to only BigQuery
When you create the OAuth credentials for your service account, you can specify the Scopes that the credentials are valid for. Each api documents the scopes required in order to call the api. BigQuery's scopes are documented here: https://cloud.google.com/bigquery/authorization.
For example, if you only provide BigQuery scopes, then your code will only be able to make BigQuery api calls. Attempting to call a Google Storage API with credentials bound to BigQuery won't work.
Related
I'm testing Azure Graph API.
and I'm trying to find an API that allows me to retrieve only users that are assigned to a specific app I created.
In app registration page, I gave a user.read.all permission, but the get user API gives me all users that are in the AD and not only that are assigned to the app I created. Should I change the permissions? or to access an another API?
Does anybody know what to do?
Thanks
Additionally, This object id should be based on service principal and not the application registration here.
You can retrieve the object Id from Azure AD->Enterprise Applications->Your app->object ID.
You need to have at least Application.Read.All and Directory.AccessAsUser.All for delegated permissions or Application.Read.All for application permission based on user or application context.
For specific details, you can add $select parameter to show only the displayName of the users assigned to the app.
https://graph.microsoft.com/v1.0/servicePrincipals/{object Id}/appRoleAssignedTo?$select=principalDisplayName
As a workaround you can use the below graph API to get the list of users.
https://graph.microsoft.com/v1.0/servicePrincipals/{ObjectID}/appRoleAssignedTo
Note: The above graph API gives the Object Types User and Service
Principle as well
As discussed in the MS Q &A Platform This endpoint currently does not support filters based on appRoleId. In fact, except that the id parameter can be filtered, the three parameters appRoleId, principalId, and resourceId do not support filtering. Similar issues have been raised before.
I'm creating users in AzureAD using graph api.
I want to enable multi-factor-authentication either while creating users using MS Graph API or else is there any other way to enable Multi-Factor-Authentication using MS Graph API.
Currently this is not available in Microsoft Graph API. I found a vote in azure feedback https://feedback.azure.com/forums/34192--general-feedback/suggestions/32683693-add-mfa-status-to-user-entity-info-returned-by-gra
If MFA authentication needs to be enforced, maybe an alternative would be to have a conditional access policy requiring MFA for a group of users (e.g. the baseline MFA for admins) and check that the user is a member of that group using Graph API.
I made it this way:
Blazor wasm client, informing the user about the process and providing information about Microsoft Authenticator install, how-to, etc.
Azure Function Rest Api, able to check a user "mfa status" and able to add a user to a specific group. Both are simply "give me status" and "give me mfa", no parameters. Everything is controlled by the token provided to Azure Function controller.
Both use authentication, meaning that the user authenticates via AAD, and this identity is presented to both api.
If the user is not already added to the group, the user gets the option to "order mfa". In the backend, the user is simply added to the group.
The group is set in Azures "conditional access".
I did not want to do this through Graph API, because then I had to give the users some "other possibilities" that i feel they not should have.
If you are using Graph Client in your back end C# project then you can Enable/Disable/Enforce Users MFA using Powershell.
Scroll down to “Change state using Powershell”
https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
I have read the documentation on Microsoft.com and have only got answers about giving Applications authorization to talk to eachother but not how to implement a permission system on each different application that I have.
I basically want to know what the best practices are to implement Authorization on my .Net API and Angular Client.
I would use Azure AD to redirect external and internal users to the Microsoft Sign-In Page, I am missing a fine grained Permission system to authorise users to access different Resources on the API or on the Angular Web Application.
Wo I have to set up a DB for my API with permissions?
How do I add new users to my DB after registering them to my AD?
Im really confused here, so my questions aren´t really as clear as I wish I could write them.
Compiling comments to a proper answer:
Per-user permissions are limited to appRoles, roles that you can give in Azure AD to users. You can also use security groups to achieve a similar thing if you want. But anything finer-grained has to be implemented on the app side.
For identifying users you can use one of two claims in the user Id token / access token. oid or sub. The oid is the unique immutable object id in Azure AD. The sub claim is a unique immutable id within your app. So every app gets the same oid, but a different sub for the same user. The oid claim is also used when calling e.g. MS Graph API to identify the user.
My use case
I have an application which allows users from different companies to access BigQuery.
As part of the login flow, the users enable access to their bigQuery account using Google oAuth2 standard workflow.
My problem
Google oAuth2 provide 1 relevant access level to BigQuery, as can be seen in oAuth2 playgound
This means that if the user has full access to BigQuery, my application also have full access.
I would like to avoid this, so in BigQuery roles terminology, described in this link I want my app to have dataEditor permission even if the user has a dataOwner permission.
How can this be done without creating a specific service account and only using oAuth2 API flow?
Suppose that I have a web application. Consider it like a Black-Box for now. I want to use a backend system to limit what a user can view/do on the app.
i.e. Sample users can only do three functions, Premium users can do 10 functions and see more pictures.
What is the best way to do it?
I'm trying to using WSO2 Identity Server, but it doesn't offer this functionality. So I've thought that maybe I can integrate it with the WSO2 API Manager and make an API that limits users' access to a certain resource. But really I cannot find if it's possible do it. Anyone know it?
Please refer to : https://docs.wso2.com/display/IS530/Access+Control+Concepts
1) WSO2IS can act as a coarse grained access manager. Your application will act as a fine grained access mnager.
It means that roles can be defined in WSO2IS, managed and assigned to user. From there Roles assigned to one user can be provided as clains with the identity token generated by WSO2IS and sent to the application.
The application, on the other side, will manage roles to permissions links.
Access control is then done at each request by the application, based on the roles presented in the Identity Token by the user and the Permissions grid based on roles in the application.
2) The access control at the application is a business logic you must implement (or at least configure if it a COTS). It is possible to outsource this logic to WSO2IS as policies on attribute (with Workflows).
Please look at : https://docs.wso2.com/display/IS530/XACML+Architecture
Jeff