4

For an application which:

  • Will use Google OpenID for account creation & authorization
    • I plan on allowing any user to "create an account" which is why I want to use Google for this
  • AWS API gateway (to route requests)
  • AWS lambda functions (to process requests)

where should authorization live? Authentication is easy, because it's handled by OpenID itself. But imagine I want to be able to have multiple user types - for this example, admin and regular user. Some of my API gateway calls will be protected by the "admin" page.

If I had AWS users, I could use the entire IAM module of AWS to associate users with groups/roles/etc and define authorization that way.

However, I don't - to AWS all my users are the same (OpenID connect users).

I could make my own authorization service to manage permissions based on some of the Google metadata but it seems like this is a common enough situation where there should be a good solution but I've yet to be able to find it.

Do I need to just have a table in an AWS RDS which tracks this? It seems a bit clunky to have to effectively write my own authorization service if I use the Google OpenID.

Improve this question
1
  • 2
    You still need an ordinary login and user management system. OpenID doesn't mean you don't have any user accounts, it only gets rid of passwords. Instead of associating a username and password with each account, you would only associate an OpenID URI. Stop thinking in terms of AWS, start thinking in terms of your application.
    – amon
    Jun 26, 2017 at 21:16

2 Answers 2

Reset to default
1

So to start with, understand that you don't actually have an authorization mechanism right now based on what you described. You have an authentication mechanism (defining who someone is) and at the moment, all people are authorized to do anything, because you have no logic that says otherwise.

To answer your question, the AWS API Gateway includes authorization options, and in my opinion that's the right place to setup your authorization. One (as you hinted at) would be using AWS IAM credentials, but they also allow for custom authorizers.

What you would do is build a Lambda that the Gateway hits whenever someone is asking for protected routes, and it validates the person has the correct permissions. This would probably be a check against a database record of some kind that associates an OpenID identity with an Admin (or other) role.

Improve this answer
-1

The correct location within an object oriented system is to secure your domain objects methods via a security proxy or a similar mechanism (AOP). This ensures that security is enforced within any usecase the domain objects participate.

There are a lot of more pragmatic solutions for smaller projects. You can secure a facade or handle security within your usecases. But be careful. If your system grows then such solutions will produce redundant security checks when you use your domain objects in different usecases.

After all, OpenId is not an authorization mechanism. It is a authentication mechanismen. It answers the question WHO you are but not WHAT you are allowed to do. Beside this authorization should be application specific. Due to single sign on authentication mechanism are highly technology specific.

So authorization should take place BEFORE or AFTER business logic is executed. BEFORE you should check if the use is allowed to perform an action. This always referes to CUD-Operations. AFTER you may filter a Set/List of domain objects the user is allowed to see. This refers to R-Operations.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.