Trying to understand how to use Cognito and API Gateway to secure an API.
Here is what I understand so far from AWS documentation and the Cognito user interface:
Clients
www-public - public facing website
www-admin - administrators website
Resource Servers
Prices - for this simple example the API will provide secured access to this resource.
Scopes
prices.read
prices.write
Again, very simple permissions on the API. Public www users can read prices, administrators can write them.
API Gateway
GET /prices - accessible to authenticated users that can read prices.
POST /prices - only accessible to administrators
Users
Administrators - can update prices via the POST method.
Non-administrators - cannot update prices.
Based on this...
Each client will request the scopes it is interested in. So for the public www site it will request prices.read and for the administration site both prices.read and prices.write.
The API Gateway will use two Cognito Authorisers, one for each HTTP Verb. So the GET method must check the user can read prices and the POST method that they can write prices.
The bit I don't see is how to put all of this together. I can make the clients request scopes but how do they now connect to user permissions?
When the token is generated, where is the functionality that says "Ok, you requested these scopes, now I'm going to check if this user has this permission and give you the right token?"
I understand that scopes ultimately related to the claims that will be returned in the token.For example, requesting the profile scope means that the token will contain certain claims e.g. email, surname etc.
I think based on this that my permissions will ultimately end up being claims that are returned when specific scopes are asked for. The fact that the two clients differ in what they request means that the prices write claim an never be returned to the public www client. It would never issue a token if the prices.write claim was requested.
What I can't see is where this fits in Cognito. There is the option to put users into groups but that is pretty much it. Likewise, there is nothing (that I could see) to relate scopes to claims.
I'm coming from a .Net and Identity Server background. Certainly in the last version of Identity Server I looked at there was a handler method where you would work out which claims to put into a token. I guess this would map into one of the custom handler lambda functions in Cognito. From there this would need to query Cognito and work out what claims to issue?
The final piece of the puzzle is how the API Gateway checks the claims. Can this be done in API Gateway or does the token need to be inspected in the Lambda function I will write to handle the API Gateway request?
Certainly using Identity Server and .Net there was a client library you would use in the API to inspect the claims and redact permissions accordingly. Guessing there is something similar in a Node JS Lambda function?
A few assumptions there as I'm basically in the dark. I think the basics are there but not sure how to connect everything together.
Hoping someone has figured this out.
Related
I have a web application where the regular user login is handled via SSO.(This prevents me from creating a service user)
In this application I have some web service endpoints that are not in the scope of any user. They will be triggered by another application and do some stuff.
Is the following the right way to do.
A token string is created by hand(because of simplicity)
The token string is stored in the environment variables of the system that provides the webservice endpoint as well as in the system that calls those endpoints.
On every call a simple equality check is proceeded - if the token is not present, the endpoint returns a 401.
Is my approach to simple?
I have not found much on this topic - my approach comes from the moodle-webservice handling, where you generate a webservice token in moodle and place it aswell in the application that calls the webservice.
For a basic application with no high security requirements, this might be ok.
A few things you could do (all of which will increase complexity and/or cost):
The service could store a proper password hash (like bcrypt, pbkdf2 or argon2) instead of the actual password. This would help, because if it is compromised, the actual key would not be lost, the attacker could still not easily call the service. (But it's already compromised, and this is not like a user password that would be reused, so it depends your choices and threat model.)
You could store this secret in a proper vault like AWS Secrets Manager or Hashicorp Vault or similar. This would enable you to control access to the key in one place, and audit key usage (maybe alert on attempts and so on). Access to the vault would still have to be managed, but that's easy via roles on AWS for example, where instances with the right role can access the secret but others cannot.
I want to implement a blog API - for fun and learning - which allows a user to manage and write/view their own blog posts. So far I have an API with paths like
/ - GET all posts,
/blog/{id} - GET a specific post or PUT to update a post
/blog/ - POST for a new blog
Using a cognito user pool, a user can sign up, and login and the API Gateway uses an authorizer to allow or deny access (I'm mucking about with Blazor at the same time - there isn't really an interface yet just a bit of cobbled together C# that uses the identity provide API}.
However, any user can see all posts. I really want something like this:
/{user}/ - GET all posts by user
/{user}/blog/{id} - GET or PUT specific blog post
and so on.
Behind the API gateway are four really simply lambda functions. So far, with the user pool authorizer I can see the Authorization header but nothing else (the request context and context have no Identity elements that are not null).
I was wondering whether I could use Identity Pool to do the specific user permissions using IAM Roles, but I cant think of what the roles might look like, or whether this seems possible. I know there are parameters you can embed in roles - you do that for S3 Roles - why not API paths?
Does this sound plausible or would I need to go down the Lambda function to do authorization? Anyone any examples? I googled and look through stack overflow, but couldn't see anything specific around this.
Another problem I guess would be getting a nice ID substitution for user here - I collect email and nickname so far - need a nice username rather than a cognito user id, which looks like they're wouldn't play well with a URL?
Thanks.
The answer to my query appears to be in this you tube video, put up by the AWS team late last night (uk time, anyway.) So far, using C#, I can authenticate myself against the user pool, and get AWS Credentials, but when I attempt to access my API I get "message": "unauthorized", and that's it!
Anyway, onwards and upwards.
You tube video about fine grained access control using cognito identity pools.
I have a client app that connects to an Elastic Beanstalk server app. Some of my users need to register. But when the registration form loads it needs to get some data from DynamoDB so the user can choose between a few options.
The problem is that I set up my server in a way that any request to the server that is not authenticated (no auth tokens previously obtained by the client app from Cognito) gets denied. Of course, if a person is going to register they are not authenticated, which means they do not have access to the information from DynamoDB they need to register. It is only a couple of pieces of information I need, so it is very frustrating.
What I have thought about how to solve this:
Putting a long string of characters in the client app that gets sent to the server when a request is made for ONLY the couple of pieces of information I need. The server would also have that same string stored somewhere and would then compare them. If they match, then it returns the info requested. As I said, this would be done only for the 2 pieces of info I need, everything else would still be secure.
Leave the two routes public in my API that lead to the pieces of info I need (I know, it is a bad idea).
What would be the best way to go about this?
Assuming you're using cognito there is also a concept of an anonymous guest user which can have its own role assigned.
You can treat the anonymous guest user like a regular cognito user (it can have a role assigned), however you would scope its permissions down to the minimum it requires to perform these operations.
Alternatively use option 2, the API could call a Lambda that would return the necessary information simply reading the data. You would possibly want to look at caching the results as well to avoid your API Gateway endpoint being abused.
I am trying to use the Google Contacts API and the Python / GDATA client handlers to access Contacts via OAuth 2.0 for users in the domain. I'm ultimately wanting to create a web service to add contacts for users, but the first step is getting this test working.
I can access my own Contacts just fine if I use the default URI. However, when I pass in the email address to construct the URI for another user, I can't seem to access the other user's Contacts. Here is the code that I'm using:
client.GetContacts(uri=client.GetFeedUri(contact_list=userEmail))
A 403 error is returned when I execute this.
gdata.client.RequestError: Server responded with: 403
Your client does not have permission to get URL /m8/feeds/contacts/<userEmail>/full from this server.
Mostly just trying to understand if what I'm attempting here is even possible. In the Email Settings API, for example, you can get authenticated to the domain and pass in a user's email to list their labels, add filters, etc. So, I would anticipate that the Contacts API would work the same, though handled slightly differently, i.e. modifying the URI, instead of just passing in an argument to the client handler. Please let me know if I am wrong in that presumption.
For authorization, I'm getting the details using flow_from_clientsecrets, then getting the token to authorize the ContactsClient for the domain. Again, I can access my own contacts fine, so authorization seems OK, but I can't access other users' contacts.
client = token.authorize(ContactsClient(domain=domain))
Seems like I'm missing something with respect to accessing other users. Is anybody able to assist me over this hump? Here are some things that I've checked / confirmed:
Contacts API is enabled for the project
Scopes have been authorized for the Client ID in the control panel > Manage 3rd party access
I am a Super Admin in the domain.
Thanks for your time!
I figured out the answer here from another post with exceptional detail:
Domain-Wide Access to Google GDATA APIs
You need to use "Service Account" authentication. For some reason, I was thinking that would only work with the newer discovery-based APIs. But, service account access also works for GDATA APIs. I can access all the Contacts for users in the domain now.
I have an internal-facing RESTful web service. There are various client applications using the service, and the client apps themselves have end users. The web service needs to authorize requests based on the end user identities.
The question: What are the typical options for authenticating the end user here? That is, I want to authenticate the user, not the client application. (I don't mind if authenticating the client application is part of the scheme, but ultimately I need to know that the end user is who I think he or she is.)
One possible scheme, for example, would be to have per-client system accounts, and then have the client simply assert the user's identity (e.g. in an HTTP request header, say). So we authenticate the client application and delegate user authentication to the client. I don't think this is a very strong scheme, though, because it depends too much on keeping the system account credentials secret. I have seen too many examples of people e-mailing system account credentials around to put much faith in this sort of approach.
Another approach might be to have the client app, upon user login, use the user's credentials to get a token from the API, and then use that token for subsequent API requests. That way the authentication is user-specific without requiring the client app to hang onto the username/password credentials.
Anyway I'd like to have a better sense for the range of options I should be considering here.
The problem that you describe with "delegated authentication" is a real one. It means that a "client application" using it's credentials has access to the whole breadth of user data. This access can be used maliciously (for example a "semi-trusted" app harvesting api data) or negligently (for example an app accidentally exposing a Direct Object Reference Vulnerability - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References)
Probably the most prevalent "token based" scheme is OAuth2 (http://oauth.net/2/), and the precursor, OAuth, which many sites choose to continue to use.
OAuth2 has a number of roles:
resource owner (the user in your case)
resource server (your api)
client (the apps you talk about)
authorization server (not clear who or what would fulfil this role in your case)
The basic scheme is that the resource owner authenticates using their credentials directly with the authorization server. They are then asked if they want to grant some information (which may just be a persistent identifier, or a description of the information exposed by your api) to some client. When they accept an 'auth code' is sent to the client and they use that (combined with their own credentials) to receive an 'access token'. This access token can then be used to authenticate against the resource server (which can check it's authenticity back against the authorization server).
Normally the way this is used is that the authorization server and the resource server are owned and managed by the same entity (for example google and facebook would fulfil this role) and then clients are independently managed.
The scheme can also be used internally within an organisation without the "explicit grant" which can still at least confirm that a specific end-user is present before releasing any data from an api.