There's new feature in aws cognito to allow user to sign in through external federation identity providers in user pool.
I followed the steps given the aws Doc.
1) select identity providers
2) attributes mapping
But when I sign up, fb/ Google account ID don't get map in user pool.
Can someone give me a proper code to do this. I mean how should I map fb/ Google user sign in programmatically in cognito user pool.
Currently, only the Facebook id, Google sub, and Login with Amazon user_id attributes can be mapped to the Amazon Cognito user pools username attribute.
What does your attribute mapping look like?
Related
I have three service accounts:
App engine default service account
Datastore service account
Alert Center API service account
My cloud functions uses Firestore in datastore mode for book keeping and invokes Alert Center API.
One can assign only one service account while deploying cloud functions.
Is there way similar to AWS where one can create multiple inline policies and assign it to default service account.
P.S. I tried creating custom service account but datastore roles are not supported. Also I do not want to store credentials in environment variables or upload credentials file with source code.
You're looking at service accounts a bit backwards.
Granted, I see how the naming can lead you in this direction. "Service" in this case doesn't refer to the service being offered, but rather to the non-human entities (i.e. apps, machines, etc - called services in this case) trying to access that offered service. From Understanding service accounts:
A service account is a special type of Google account that belongs to
your application or a virtual machine (VM), instead of to an
individual end user. Your application assumes the identity of the
service account to call Google APIs, so that the users aren't
directly involved.
So you shouldn't be looking at service accounts from the offered service perspective - i.e. Datastore or Alert Center API, but rather from their "users" perspective - your CF in this case.
That single service account assigned to a particular CF is simply identifying that CF (as opposed to some other CF, app, machine, user, etc) when accessing a certain service.
If you want that CF to be able to access a certain Google service you need to give that CF's service account the proper role(s) and/or permissions to do that.
For accessing the Datastore you'd be looking at these Permissions and Roles. If the datastore that your CFs need to access is in the same GCP project the default CF service account - which is the same as the GAE app's one from that project - already has access to the Datastore (of course, if you're OK with using the default service account).
I didn't use the Alert Center API, but apparently it uses OAuth 2.0, so you probably should go through Service accounts.
Is it possible for my server to get credentials for a user without their username and password in order to send it back to the client?
I have another means of authentication and I think this would be easier to do this rather than trying to store tokens in a database where they will expire.
Yes. You can provide alternatives to Username/Password to login a user. Developer Authenticated Identities Authflow let your server take the place of the user pool or other social identity provider.
User Pools are just that, an AWS hosted authentication tool. They let users prove they own a specific login string (email, phone, etc.) by providing a password. Then that user is mapped to an Identity in an Identity Pool.
You can also use Facebook as the "proof" and get an Identity ID that way. If you pass both (User pool and Facebook) tokens to the Identity pool at the same time you will link those two login ID under one Identity ID. Now you can log in using either method and the app will treat you as the same person because you have the same Identity ID.
You can implement a server which will let you act as that same type of provider so that users can prove to your server they are who they say they are then you can signal to the Identity pool that they are "X" person.
The thing to remember is that the User pool is used to store and validate username/password combos (and some other attributes if you want). The Identity pool is used to map 1 or more logins (Facebook, Google, User Pool, etc) to an Identity Id that your app(s) can use to identify/differentiate users.
No you would have to either, at least authenticate once with Cognito (afterwards use refresh tokens to obtain new id/access tokens without having to enter username/password) or federate with another Identity Provider (but you would still have to authenticate with that identity provider).
I'm new to AWS and I really need help with this. I have an existing RDS Schema with Users table and also with my own Users authentication algorithm/system using JWT. Everything was fine until I reached working on uploading files to S3. I discovered that when uploading to S3. We cannot pass extra parameters but only the body, key, contentType and to which bucket. I wanted to pass extra parameters like the current logged in user's access token (for user validation security), user_id, photo title and caption. But it's not possible.
What should I do? Should I use AWS Cognito User Pools instead of using an RDS Users? If I use Cognito User Pools, is it possible to do a SQL Query like joing a Cognito User and another RDS Table? I'm so confused. I'm sorry if I sound like an idiot. But I really need some help about this.
I hope somebody can. I would really appreciate it. Thank you very much in advance.
I am assuming your upload logic is in Lambda. In this case you can just do your authorization for the upload in the Lambda function. Allow the Lambda function to upload data to S3 by attaching an IAM policy to the IAM role that Lambda uses.
If you upload to S3 directly from a client, then you can either do that without authentication/authorization or use Federated Identities. In this case you can either export all your users to a Cognito User Pool (and keep them in sync) OR create your own Identity Provider and register your users for a Cognito Identity Pool.
The cleanest, but probably also hardest, way is to keep your authentication, integrate with the Cognito Identity Pool via OpenID, SAML or your own method (see http://docs.aws.amazon.com/cognito/latest/developerguide/developer-authenticated-identities.html).
You should go that way only if a) your authentication is really good and b) you have verified that having the user in a Cognito Identity Pool actually meets your requirements/business rules.
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.
Is there any available SDK of Twilio or Authy to use for Two Factor Authentication with Cognito?
Or What are the best practices to do User Authentication via Cognito with Two Factor Authentication?
Basically how mobile app authenticate user with Two Factor Authentication by using Cognito for Identity Management?
One important clarification - Cognito doesn't manage users for you. Cognito leverages public providers (facebook, google, amazon, twitter, an existing external provider...etc.) to generate AWS credentials for whatever user 'signs in'. Additionally, there isn't a native MFA mechanism in Cognito as of now.
With that in mind, it should be possible to do it yourself, however you would need to build some additional mechanism. Say you were trying to log into facebook - the common flow would be to:
1) open up app
2) click sign in button
3) sign in to facebook
4) app validates login with facebook, gets generated token
5) app gives generated token to Cognito, gets an id and credentials.
To catch the login event, you would need some kind of back end that intercepts the login event and has some kind of mapping of login to means of authentication, then once that provider approves the login, you can trigger the auth text/push notification...etc.
Update: this is no longer true, the Cognito User Pools service does manage users for you and allows SMS MFA for authentication.