pygeoapi
pygeoapi copied to clipboard
geopython
Support authentication and authorization for the different APIs and collections
Is your feature request related to a problem? Please describe. Access control is a complex and huge topic and there is plenty of specific software to support the whole identity and access management lifecycle. It would be good to have modular, agnostic and pluggable support for controlling both the authentication and the authorization part of a collection. In parallel, we should align to the various specifications about the security mechanisms to be implemented. As an example, the transactions of OAFeat Part 4.
Describe the solution you'd like A clean and lean solution that can be plugged and configured at configuration level and might support external identity providers via OpenID Connect protocol but even a native very-basic internal mechanism like for example a TinyDB/python provider for authentication and authorization.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context Add any other context or screenshots about the feature request here.
Hi @staffordsmith83 @francbartoli. Have also been thinking on authentication and access control needs for pygeoapi.
Given the vast array of authentication services and combinations of access permissions, a starting place could be a plugin based authentication. It could operate similar to the processing plugin where there is a base authenticator providing default access to everyone. The provider could have methods for checking authentication, checking access, adding a user, removing a user, modifying a user? Like you mentioned, @francbartoli, a simple plugin could be bundled with pygeoapi using tinydb which would implement the aforementioned methods while actually authenticating and determining access to resources.
This idea came about in a conversation from earlier today, so many questions still remain in my mind. The first that come to mind are What would the configuration look like? Would we only wrap methods that interact with data in the plugin? I would be interested to hear both of your thoughts (@tomkralidis as well). I am interested in helping this mature however we decide best.
Hi @staffordsmith83 @francbartoli. Have also been thinking on authentication and access control needs for pygeoapi.
Given the vast array of authentication services and combinations of access permissions, a starting place could be a plugin based authentication. It could operate similar to the processing plugin where there is a base authenticator providing default access to everyone. The provider could have methods for checking authentication, checking access, adding a user, removing a user, modifying a user? Like you mentioned, @francbartoli, a simple plugin could be bundled with pygeoapi using tinydb which would implement the aforementioned methods while actually authenticating and determining access to resources.
Yes @webb-ben, that makes sense. To be agnostic and open to the variety of different mechanisms I would keep some concepts completely separated. For instance:
authentication --> authn plugin
authorization --> authz plugin
internal login --> route to be added
user provisioning --> route (i.e. /users) to be added for the CRUD and protected by the aforementioned plugins for administration
permission provisioning --> (i.e. /users/<user_id>/permissions) to be added for the CRUD and protected by aforementioned plugins for administration
Also, authn and authz, in my opinion, should be injected as dependencies to the request (avoiding as much as possible strong coupling with the pygeoapi API) and while it flows along the routes (and thus compared with the configuration) they can provide a basic method like is_authenticated() and is_authorized() with a boolean result for the access.
So in theory we can mix up different authentication/authorization mechanisms at the collections level in the configuration and support at the same time transparently the different frameworks
This idea came about in a conversation from earlier today, so many questions still remain in my mind. The first that come to mind are What would the configuration look like? Would we only wrap methods that interact with data in the plugin? I would be interested to hear both of your thoughts (@tomkralidis as well). I am interested in helping this mature however we decide best.
I'd like to come up very soon with a draft proposal
What about passing the flask request object directly to provider's "query" and "get" methods? This would delegate both authentication and authorization at query time and leave the solution framework agnostic.
What about passing the flask request object directly to provider's "query" and "get" methods? This would delegate both authentication and authorization at query time and leave the solution framework agnostic.
Delegation of security at the provider's level looks to me very coupled. Also, you would lose the benefits of using external tools, for example, authz providers like Open Policy Agent that would allow delegating the yes|no permission at route level for each HTTP method.
You are right about the Open Policy Agent case, however, I believe that some pattern can benefit from direct access to request object. There can be a need for more granular control in aggregating individual objects (features) i.e. based on rules dictated by headers set by an API gateway. In these cases, it may be necessary to access the request object to parse them and the provider's "query" and "get" methods looks to be the place to do it efficiently.
Anyway the project looks very promising, thank you!
Since the OGC API specs want to be very agnostic around security and how that would be implemented, the pygeoapi project, as a reference implementation for some of them, aims to follow the same principle accordingly. I'm going to close this ticket as the security aspects will be implemented in external plugins or downstream project like https://github.com/geobeyond/fastgeoapi for example