Account Locked claim works fine for basic authenticator, but for Facebook and Google identity providers I still can login into my application for locked users.
Please, help!
Account Locked claim is a local claim and can only be used for local users (users who are in a configured userstore). For federated users you may try associating user accounts and setting associated local user account's Account Locked claim.
Related
Consider this scenario:
I have two domains: domain1.net and domain2.net.
I have GCP enabled on domain1.net and created a Service Account here that has Domain-Wide Delegation Enabled.
The CLIENT ID from this Service Account is configured on domain1.net GSuite Admin Console as domain wide delegation and has the following OAuth2 scopes enabled:
SCOPES = [
'https://www.googleapis.com/auth/admin.directory.group',
'https://www.googleapis.com/auth/admin.directory.group.readonly',
'https://www.googleapis.com/auth/admin.directory.group.member',
'https://www.googleapis.com/auth/admin.directory.group.member.readonly',
]
I have a Cloud Function that uses the Service Account's rights to create a OAuth2 JWT, to be able to access GSuite domain1.net APIs. Code Sample Here.
The user to impersonate in GSuite has Group Admin Roles to be able to create GSuite Groups.
All this configuration works perfectly, I am able to create Groups in domain1.net using a Cloud Funtion in domain1.net GCP env.
But if I use the same Service Account CLIENT ID in domain2.net give the same OAuth2 Scopes, create an user with Group Admin Roles and use this user to create new groups, it doesn't work.
Error:
error got with oauth2client==4.1.3
oauth2client.client.HttpAccessTokenRefreshError: unauthorized_client: Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested.
error got with google.oauth2:
googleapiclient.errors.HttpError: unauthorized_client: Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested.
Now the above error code: unauthorized_client found in this documentation specifies that the CLIENT ID is incorrect and I've might have used the Service Account's email, which I did not.
Is Domain-Wide Delegation cross GSuite organization(different domain) capable?
I know that it works in any sub-domain of domain1.net but not in any other GSuite organization(different domain like domain2.net).
I have good news for you (This won't answer your question but will solve your problem)!
You won't need to impersonate an admin anymore to create groups. Google just last week announced that the Cloud Identity Groups API will now allow for Group Management via API w/o impersonating an admin.
Take a look at these update blogs:
https://gsuiteupdates.googleblog.com/2020/08/use-service-accounts-google-groups-without-domain-wide-delegation.html
https://gsuiteupdates.googleblog.com/2020/08/service-accounts-in-google-groups-beta.html
https://gsuiteupdates.googleblog.com/2020/08/new-api-cloud-identity-groups-google.html
I can't help you with the actual question, tho; that's just not my territory.
A service account belongs to the application for which you created it. If this application belongs to domain1.net, the service account will be able to impersonate accounts from domain1.net, not from any other domain.
If you want a service account to impersonate users from domain2.net, create another service account on a GCP project that belongs to domain2.net.
Reference:
Using OAuth 2.0 for Server to Server Applications
Suppose a user signs in with Google. Then later the user for some reason gets locked out of their Google account. Can they also sign in with Facebook and access the same Cognito account (Assuming they have the same email address registered with both Facebook and Google)?
Yes you can add multiple federated identities to a single User Pool. Just add multiple providers in cognito user pool settings. And yes the account is the same so if you lose your google account you will still have access through facebook as long as your email address for both of these services is the same.
I don't get the difference between the User Pools > Identity providers and
Federated Identities > Authentication providers.
Can someone explain?
Identity pools (Federated identities) allow you to grant users authenticated by third parties (e.g. login with Google) temporary IAM credentials to use you AWS resources in a limited way. Identity pools are free of cost and you only pay for the resources your users use via the IAM credentials.
User pools allow you to store your own users, they can sign up directly to the user pool and not have to use a third party provider like Google or Facebook. Confusingly user pools also have a 'federation' option (Identity providers) but this will actually create externally federated users in the pool. User pools provide OpenID tokens (access, id, refresh), not IAM credentials, which you can use with your own endpoints (ec2, fargate, api-gateway). User pools have costs associated with them based on the active users per month.
I am setting up an AWS Account, the account will be used by an organization of employees for EC2 use/experimentation. Obviously, I do not want to distribute the root login info or set up one single IAM user for everyone to use. Unfortunately, I do not have the time to manage creating individual IAM users for everyone on a regular basis.
So, is there a way to auto-create IAM users based on a given email's domain on their first login attempt? The users should have read-only roles to begin, then an Administrator could give more roles as needed to each user. I am open to suggestions, perhaps lambda functions or linking to an identity provider?
Keep in mind that these new IAM users need to have access to the AWS Management Console, this is not necessarily intended for login to applications hosted on AWS.
Update:
Moving forward using this AWS Management Console Federation Proxy Sample found in Amazon's code reference, using with Microsoft Exchange hosted email.
If your existing identity provider supports SAML2 Federation, you can set it up to login to the AWS Management Console.
For more details refer Enabling SAML 2.0 Federated Users to Access the AWS Management Console.
Else you can implement a custom Federation Broker to return an URL to the user, after they authenticate with their corporate credentials.
For more details refer Creating a URL that Enables Federated Users to Access the AWS Management Console (Custom Federation Broker).
We have implemented a Developer Identity Provider using our custom user auth service and we have an Identity Pool connected to it with many Identities saved. Right now, we're evaluating to move our user table to a User Pool connected to the same Identity Pool and use the mobile-hub library.
The question is: After the import, could Cognito detects if a user with a specific username already exists in the Identity Pool and doesn't create it again (with another Identity)? Self signup is activated.
UPDATE for clarification:
Our identity pool has near 1000 existing identities. All of them were created before the existence of User Pool feature. They were created using the "Developer Authenticated Identities Authflow" (check link), and the external "Developer Provider" is a simple user table. Each identityId in the Identity Pool is associated to an existing identity (record) in our external user table.
Now we want to use AWS Mobile-hub lib in our iOS app and a User Pool connected with the existing Identity Pool. We want to start adding new users to our User Pool but for existing users, they already have an identity created in the Identity Pool. What to do in that case?
Seems to be that, at the moment of first login, Cognito doesn't have a mechanism to detect if a user already has an IdentityId created by another auth flow (Facebook, Developer Provider).
You could do one of a few things, because as you noted, Cognito does not totally handle this for you.
If you're all in on user pools, you could use the import user feature to transfer your users.
Alternatively, on sign in, you could check if the username exists in your user table. If so, you could either sign them in by that, or you could transfer them over to user pools then and there with a lazy load.