I need to know how can I restrict access to Azure Storage containers/blobs for certain roles like I want users with Admin role to access container A & B and I want users with HR role to access only container B and not A, how to achieve this?
You should take a look at SAS, shared access signature provides you with a way to grant limited access to objects in your storage account to other clients, without exposing your account key. It's through the setup of policies, checkout the below screenshot(it can be done via code or Azure portal):
More Details about SAS can be found here: https://azure.microsoft.com/en-us/updates/manage-stored-access-policies-for-storage-accounts-from-within-the-azure-portal/
Related
I have a question similiar to LDAP authorization but more specifically to OBIEE and Microsoft AD.
As described in documentation, if I use BI Publisher I only need to create a couple of XMLP_% roles in Active Directory and grant them to users after AD authentication is set up.
My questions are:
Can I use similiar approach to using Analytics?
Am I obligated to use external store for user roles?
Can I use DefaultAthenticator provider for roles and grant them to Active Directory users?
I want to use existing tools only if possible. Which options do I have for storing roles apart from database tables?
You don't need to create anything inside the AD at all. You just map whatever AD groups you want to OBI application roles.
DefaultAuthenticator is the WLS-embedded LDAP. Leave that alone, otherwise you lock out your "weblogic" admin account.
Here is the scenario, I have a service containing many records. My service also has many users, each with the ability to create, read, update and delete records. The ability to perform these operations on each record must be controlled at the record level.
For example, user A can only read and update record 1 but user B can read, update and delete records 1, 2 and 3 and user C can perform all operations on all records.
How if at all, can this be done using Azure AD?
Obviously, using application roles is not sufficient because that gives the user uniform access rights to all records.
The tenant is also not useful because its the same for all users (in this example).
I definitely do not want to define access rights for every record individually, I would like to do something like assigning roles to a user group and then somehow assign records to the group.
Is there a standard way to deal with this type of resource based authorization?
As you correctly mention, role based access or authorization is very generic and using that, a user with specific role gets access (or gets denied access) to all resources. (If your sceanrio permits, you could make it a little better by dividing your resources into a few types and give access for 1 or more types of resources to 1 or more roles).
When trying to control access for each record individually, you will need to implement custom logic for resource based authorization. Typically applications utilize a mix of role-based and resource-based authorization driven by their requirements.
In the end it will boil down to a mapping that you need to maintain between 3 things
Resource (or a collection of resources)
Azure AD object (like role, group, individual user that is being given permission)
Permission that you're giving (understood and enforced by your application e.g. Blogs.Create permission for a Blogs application)
Relevant Documentation available on Microsoft Docs
Role-based and resource-based authorization
This documentation talks about similar concepts and shows a good example which makes use of both role based and resource based. CRUD operations on resources based on roles and then special privileges on specific resource for the owner of that resource (i.e. resource based)
Code Samples
Multi-tenant Survey Application Code
Code base for the documentation link above
Authorization in a web app using Azure AD groups & group claims
This one provides a sample task tracker application where users can share tasks with other users or Azure AD groups. Again you will see a mapping between resources (i.e. tasks in this case) and Azure AD objects (i.e. Users or Groups) is being maintained in sample database.
Assigning Application Roles for groups
Since you mentioned this as part of your question, just letting you know that this is possible from Azure Portal but only if you have Azure AD Premium license (I'm not sure which specific ones support it, but search on Group based assignments feature and you'll find it.)
I am trying to build a pure JavaScript rest-client application that must support anonymous retrieval of information from a REST server that already supports JWT for authentication/authorization for external applications. The server is already being used by other client applications supporting multi-tenancy. Actually embedding the tenant information in the JWT.
Besides that the application needs to support users(human beings) that will want to mark(or select) some resources as favorites so a mechanism is needed for users/role creation and further authentication/authorization for the users. But these users can't be isolated to a single tenant, they will want to use across tenant resources.
So, right now I found that I need to use a JWT value for the anonymous data retrieval that of course should be tenant-agnostic. This means that I have to create an user with a special role that just have permissions for read only resources, except for the permissions for user creation (when the clients do sign up) again this should be tenant-agnostic. And when the user log-in into the system the JWT should be replaced for the one that have the user credentials again tenant agnostic. I am not sure if this is entirely correct, so how should we handle a situation like this ?
My other concern is, that we have the same back-end supporting authentication and credentials storage for human clients (tenant-agnostic) and application clients (tenant-aware), so there is logic that is a little bit more complicated in order to handle the privileges and tenant restrictions here. This could be just my impression but I feel that there should be a separation between application users and human users in the logic and/or data store.
But I am not completely sure and I want to know if some of you have previous experience or could have some ideas about this topic ?
Can you try the following approach, Create the users, assign the users with a read-only role for the tenants to which they need access to.
The data would be like
User1 - tenant1 - administrative role
User1 - tenant2 - data reader role
User1 - tenant 3 - user role
In the jwt, we ensure that the user is authorized. Then we get the list of accessible tenants and see if he has access to the requested tenant data w.r.to the above data and then complete the authorization.
HTH
I am planning a game app for mobile devices. Users will log into the game using their existing social media account to streamline data capture. Company B would like to directly save player data and scoring information from the mobile app to a DynamoDS table named Score Data When a user saves their game the progress data will be stored to the Game state S3 bucket.
What is the best approach for storing data to DynamoDB and S3?
Option 1: Use an EC2 Instance that is launched with an EC2 role providing access to the Score Data DynamoDB table and the GameState S3 bucket that communicates with the mobile app via web services.
Option 2: Use temporary security credentials that assume a role providing access to the Score Data DynamoDB table and the Game State S3 bucket using web identity federation.
Many architects I talked to Option 1 is the right one. But according to AWS doco, it appears Option2 can be valid too. Any inputs would be appreciated!
I would strongly consider Option #2 using Amazon Cognito to provide temporary credentials to your users that enable them to directly and specifically access DynamoDB and S3.
Generally speaking, you need to:
Create a new Cognito Identity Pool and set up 2 IAM roles -- one for authenticated users and one for unauthenticated users (optional). https://docs.aws.amazon.com/cognito/devguide/getting-started/?platform=ios
Authenticate a user via your own authentication provider or via external providers like Facebook, Twitter, etc., and then use Cognito to create temporary credentials for them. https://docs.aws.amazon.com/cognito/devguide/identity/external-providers/
Use the credentials to access DynamoDB and/or S3. Your AWS resources will be protected as long as you set up your IAM roles appropriately. For example, you can give fine grained access to your DynamoDB table so that users cannot access rows that don't belong to them. See the following link for more details: https://docs.aws.amazon.com/cognito/devguide/identity/concepts/iam-roles/
The Cognito developer guide is here: https://docs.aws.amazon.com/cognito/devguide/.
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.