I have an application which allows OpenID Connect login. I need to be able to give the users admin/read-only access based on their roles or group membership. With Keycloak, I can configure the Client settings to include roles and groups in the JSON Web Key my application receives, and I can set up mappings within the application to assign the correct permissions to various roles or groups of users (depending on the mapping).
I'm surprised that I have not been able to find any clear answers to this mundane problem. Is nobody using Google in such a setup within their organization or am I missing something obvious?
I tried requesting various scopes related to groups or roles based on this document, but even though the consent page has changed to reflect this, the JWK did not contain any useful information.
How do I configure Google's authentication to return group membership or assigned roles in the token?
I don't think you can add more information to the ID Token that you get from Google. According to Google's OIDC discovery document, these are the claims that can be present in the ID token:
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
]
Apparently, an organization administrator can limit which claims do end up in the ID token, so you might get a subset of these.
You should be able to get information about the user's group from one of the myriad APIs that Google exposes. Not sure if Cloud Identity is the one you're after, but there is an endpoint that returns information about groups: https://cloud.google.com/identity/docs/reference/rest/v1/groups.memberships/get If that's not the one, I think you could search the scopes page that you linked, and you should find the relevant scope there. The scope will be tied to a concrete API and this will be the API that you have to call to get the user's groups, roles, etc.
Related
I am currently trying to set up a fine grained permission system for our infrastructure. We run each development stage in a different AWS account. Each stage therefore has different secrets that are used.
I now want to add a permission set to our SSO setup that allows GetSecretValue for secrets in the account if the user has the tag for the stage, e.g. user has the tag "develop = true", then the user can access the secret in our develop account, which also has the tag "develop = true".
To give the user the related tag, we want to use SAML assertions. We can not use existing default tags (e.g. Department), since aws resource tags do not support proper evaluation of multiple values (e.g. a tag on the secret like "Stage"="develop,test" allowing develop and test users access).
I can however not get the SAML assertions for custom attributes to show up in the AWS SSO user, no matter what I do. We set the attribute as
https://aws.amazon.com/SAML/Attributes/AccessControl:secret_test. This works if I use "Department" instead of "secret_test" (I assume because Department is one of the SCIM defauilt attributes), but not for my custom attribute "secret_test".
Hence my questions are:
Is it even possible for AWS SSO ABAC to "see" and evaluate attributes created as SAML Assertions in Azure AD, if they are not default attributes?
Alternatively, is there a way to write a policy to evaluate for a part of the string instead of a full match? i tried filling "Department" with "develop/test" and then setting up a condition on the permission set like
"Condition": {
"StringLike": {
"aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
}
}
but that doesn't allow access for the user.
Disclaimer: https://console.cloud.google.com/support/community leads here. Google's documentation is horrific so giving this a whirl on the off chance that I don't get downvoted to the depths of dev/null
Out of impending necessity I am migrating a private application that monitors our Gmail accts to OAuth 2, and as part of this process it was necessary to create an OAuth consent screen. Since this application will only be used internally it makes the most sense to choose "Internal" for Application Type - which is described as follows:
Only users with a Google Account in your organization can grant access to the scopes requested by this app.
The users on this Project consist of two "owners" — myself using my personal Gmail acct, and
another employee who is part of the company G Suite account.
My question is who qualifies as a "user in my organization"? Is this based on the project owners? Does my non-G-Suite account (which is an owner of the project) qualify? Does the inclusion of one member in a G Suite account automatically associated the other employee accounts? Is the anywhere to actually see these users or manage them directly?
I'd actually like to add another couple accounts to the mix but still keep the application private, but I'm confused about how Google determines which gmail accounts will be able to authorize the app.
UPDATE: To clarify, when I visit the consent page while logged in as a member of our G Suite on the same domain as the project owner, everything is fine. However, we have other members managed in the same G Suite account who are under a different domain and for these I get the message:
Error 403: org_internal
This client is restricted to users within its organization.
Furthermore, I am not even able to grant access using my own email which is the creator and owner of the application. I'd like to know how I can add myself and the other G Suite members to be able to grant access to the application without making it public. It was suggested below that I add them (or their domain) to Google Cloud IAM but I'm unclear about how to get this working. My own email does already exist in IAM with role of "owner" and apparently that doesn't satisfy the requirement.
In order for internal apps to be used for OAuth, the project must belong to the organization associated with the same GSuite customer as all the users.
non-GSuite accounts cannot be used by internal apps. There's more information about this here: https://support.google.com/cloud/answer/6158849#public-and-internal.
Who is a member of my organization?
Anyone that you have added to Google Cloud IAM for a project, folder or at the organization level. This can include Google Accounts (Gmail email addresses), G Suite and Google Identity. The last two use a domain name (example.com) and anyone with an identity in that domain (someone#example.com).
Google's goal is to tighten up security for Google Cloud Platform. In the past anyone with a Google Accounts email address could use your projects OAuth to request access. The level of access is controlled by OAuth Scopes. Today, granting that access results in a Consent Screen with an unverified application warning. To get beyond (remove) that warning often requires a security audit of your application with a cost estimated at $75,000 USD.
How do I manage members?
Through Google Cloud IAM. You can add and remove members; assign and remove IAM roles attached to member IDs. Through G Suite or Google Identity by adding or removing member accounts. Don't forget that members can be part of a Google Group and part of a Domain each of which are also an identity in Google Cloud Platform.
For GSuite Users:
Cloud IAM only deals with authorisation you would need to handle authentication elsewhere. By default GSuite integrates with CloudIAM as a default authentication provider.
For Non-GSuite Users:
You can use cloud identity free edition but users will have to manage separate set of credentials.
Single Sign On without GSuite
If you want Single Sign On Option you can also use Google Cloud Directory Sync to sync with your on-premise Active Directory or LDAP server for authentication. So users can keep their login details.
That's how authentication works on GCP. As for authorisation you have CloudIAM where you can manage access through Predefined Roles, Primitive Roles and Custom Roles.
Cloud IAM and Authorisation
Typically you assign access using google groups and resource hierarchy to make it easier for you to manage user access. But bear in mind that if you grant an access to something through a ascenstor folder in resource hierarchy then you can't deny access downstream. So you need to plan access hierarchy accordingly.
To answer your question who qualifies as a "user in my organization"?, everyone can login but by default they cannot access any projects, it's resources or apis unless they are given access to either individually or through a group.
Hope this clarifies things for you a little.
Prior to Google's restructuring of Cloud API access, I had a gmail account that had access to a bunch of Google Analytics accounts, through which I established API access via OAuth credentials for a large number of sites. They changed their policies and began requiring domains to be verified before they could access credentials. This was the case for "public" applications, but if you switched it to "private" the domain verification no longer mattered. I had to do this because making the project public was a violation of the TOS. However, this coincided with the introduction of GCP's IAM permissions setup that forced me to create an "organization" and a "project" - and also forced me to create a Google Cloud Identity.
The stipulation of a private project was that you can only grant access to accounts under your organization. I added my gmail account to the organization and gave it administrative permissions.
So, I'm here: I set up new OAuth credentials for a new site, then try to access the API through those credentials. During the initial authorization screen, it asks me to select the appropriate Google account, and then is SUPPOSED to ask me to allow access. Instead, I get this error:
Authorization Error
Error 403: org_internal
This client is restricted to users within its organization.
BUT, the account I selected has been established as an administrator of the organization under which the API project resides! I have tried a billion different things, and the only way I seem to be able to grant access to ANYTHING is if I create the credentials under a different project and the log in with the GCI account. HOWEVER, that's not the account that has access to the Google Analytics, so it doesn't help me one bit.
To top it all off, Google has absolutely no support for this. They send me here, to Stack Overflow, to get support. Can anyone help?
The accepted answer didn't help. What helped were the following steps:
Go to Google Developer console (https://console.cloud.google.com/apis/credentials/consent?project=XXX)
Change User Type to External
Note: This does not make your site publicly accessible. It makes it so users outside your organization can be granted the normal way via IAM.
Linking an external email address does NOT make that identity part of the organization. Create a new identity based inside the organization. If your organization is example.com, create an identity such as john#example.com and use that identity. Your other option is to remove the restriction.
My production environment uses AWS cognito federated identities (AKA: identity pool) for allowing users to sign in with their Google/FB accounts. This is working fine.
However, for my staging environment I want to offer a similar sign in functionality (that is: users sign in in via Google) but I want to restrict the ability to sign in only to a specific whitelist (of, say, #gmail.com accounts). This is because the staging environment should only be accessed by team members and a bunch of trusted users.
My question is this: is it possible to define a Cognito identity pool that allows only the whitelisted users to sign in? if the answer is "yes", then how?
I know that I can do the whitelist checking at my backend (that is: at the backend of my staging env. I will reject every request not coming from these whitelisted users) but this is a bit unclean. In particular, I want the rejection to happen as early and possible and, ideally, to be carried out by cognito itself, and not by my backend.
Clarifications:
I mentioned a list of #gmail.com accounts as the whitelist. I am open to any other mechanism for defining the whitelist.
In a way I am asking whether I can have user directory functionality (in particular: determining if a user is in a certain group of users) with an cognito identity pool.
The purpose of the Identity pool is to provide access to authenticated identities. Therefore, this resource cannot manage users (ie: white listing a user group).
There are two ways to do this:
Link 3rd Party Identity into a User Pool and white list by User Group. Your user group will have a Roles and permission it will assume that will allow your test users to have the functionality they need without allowing other users who log to have that functionality.
Manage users from the 3rd Party Identity - I am not an expert at Google authentication.. but some OpenID providers allow you to create user groups with different access roles. This is an example for Google.
You can invoke a trigger and execute a lambda function when the user submits their information to accept or deny the sign in request.
I'm attempting to develop an application architecture almost exclusively on top of AWS services.
This application has both User and Organization "entities". As one might except, a User may be an admin, role-x or role-y of one or more organizations. (role-x and role-y are just placeholders for some role with some set of specific permissions. A User may also be standalone (that is, not have a role on any Organization).
Our current thinking is to use DynamoDB to store organization and user specific data. For users this may include some basic information (address, phone number, whatever), and for organizations it may include fields like "mission statement", "business address" and so on.
An admin of an organization would be able to edit all organization fields, whereas a role-x might only be able to update "mission statement" while reading all other fields.
Since I mentioned that a single user may have roles on many different organizations, that might look something like:
user1:
organizations:
123: 'admin'
456: 'role-x'
789: 'admin'
It's also worth noting that these role assignments are modifiable. New or existing users may be invited to take on a specific role for an organization, and an organization may remove a user from a role.
This is a fairly straightforward type of layout, but I wanted to be very clear about the many-to-many nature of the user, org and roles.
I've been reading IAM and Cognito documentation, as well as how it relates to fine-grained control over DynamoDB items or S3 buckets - but many of the examples focus on a single user accessing their own data rather than a many-to-many role style layout.
How might one go about implementing this type of permission system on AWS?
(If policy definitions need to be updated with specific Identities (say, for an Organization), can that reliably be done in a programatic way - or is it ill-advised to modify policies on the fly like that?)
The above answer is outdated.
AWS has added Cognito-Groups recently. That provides more flexibility
You can use technique described in the article to achieve that:
https://aws.amazon.com/blogs/aws/new-amazon-cognito-groups-and-fine-grained-role-based-access-control-2/
Unfortunately the kind of permission system you are trying to implement is not possible with Cognito at the moment. With Cognito you can currently create unique identities for your users in an identity pool. Users can authenticate using any external provider such as Facebook, Amazon, Google, Twitter/Digits or any OpenId Connect Provider. Users can also authenticate through your own backend authentication process. After the user authenticates, Cognito creates a unique identity for that user. There’s a concept of an identity, but there’s no concept of groups. All users/identities within a one identity pool can get credentials from roles associated with that identity pool. Currently you can specify two roles: One role for authenticated identity and one role for unauthenticated identity. There’s no such feature at the moment where you can specify multiple groups for each identity and specify role on that group.
For more information on Cognito, you can refer to
https://aws.amazon.com/cognito/faqs/
http://docs.aws.amazon.com/cognito/devguide/getting-started/