Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Authentication/Authorization #10

Open
sleipnir opened this issue Feb 4, 2021 · 1 comment
Open

Add Authentication/Authorization #10

sleipnir opened this issue Feb 4, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@sleipnir
Copy link
Member

sleipnir commented Feb 4, 2021

I think it is worth adding an authentication and authorization mechanism.
This could be done via Adapters, supporting different implementations. We could support basic authentication and Bearer tokens.

Research material:

https://elixirschool.com/en/lessons/libraries/guardian/
https://github.com/vanetix/elixir-keycloak
https://github.com/peburrows/goth
https://github.com/scrogson/oauth2

grpc handle metadata
https://github.com/elixir-grpc/grpc/blob/eff8a8828d27ddd7f63a3c1dd5aae86246df215e/interop/lib/interop/server.ex#L84

@sleipnir sleipnir added the enhancement New feature or request label Feb 4, 2021
@sleipnir
Copy link
Member Author

sleipnir commented Feb 4, 2021

I still have a very vague idea, but for me I divide this into two parts, which would be:

1. A mechanism to ensure that the administrator defines which users have access to which resources. 
  Very similar to what you have today with ActiveMQ, RabbitMQ, Kafka, or whatever. 
  You have users and define what topics or resources those users have access to. 
  For example: User X can subscribe and post to topics dummy.x and dummy.y and user Y can write 
  to topic dummy.x but cannot read from topic dummy.y.
  
2. A way to validate requests to the broker in an attempt to identify the user of that request. 
   This can be done using the gRPC metadata mechanism, where the user would forward a token of any kind. 
    This token can in turn be validated against any OAuth provider or any other internal
    authentication mechanism such as basic authentication. In other words, in the first case, 
    the user would obtain a token from 
    an OAuth provider and confront it during requests to Astreu that would be integrated 
    via OAuth with the Provider. 
    In the second case it could be done via configuration files or against some other persistent mechanism.

That said, the flow would basically be to send a token when trying to connect to Astreu and Astreu to validate the token against some authentication / authorization mechanism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant