You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Julian Hyde <jh...@gmail.com> on 2023/05/01 17:58:17 UTC
Re: Authentication and authorizations in Calcite
Thanks for digging these up, Stamatis.
I have logged https://issues.apache.org/jira/browse/CALCITE-5681 for DDL (GRANT and REVOKE commands).
Contributions welcome.
Julian
> On Apr 29, 2023, at 6:53 AM, Stamatis Zampetakis <za...@gmail.com> wrote:
>
> Following up on the authorization part lots of things can be achieved
> through the use of views. Views can be used to restrict the columns
> and rows that are visible to certain users and it is a common way of
> handling permissions.
>
> Here also two other JIRA tickets with discussion around this topic:
> https://issues.apache.org/jira/browse/CALCITE-2194
> https://issues.apache.org/jira/browse/CALCITE-5292
>
> Best,
> Stamatis
>
>
>
> On Sat, Apr 29, 2023 at 2:11 AM Julian Hyde <jh...@gmail.com> wrote:
>>
>> I think Calcite should stay out of the authentication business. The container (not Calcite) should authenticate users and convert them to security principals that Calcite knows about. (Avatica does authentication [1] but it just delegates to a provider.)
>>
>> Regarding authorization. I support adding a grants system to Calcite. Grants could be created via DDL (GRANT, REVOKE commands) or via APIs (like interface Schema) and the validator should enforce them. E.g. principal1 can see table1 but is not allowed to see its columns column2 and column3.
>>
>> If you’re interested please log Jira case(s).
>>
>> Julian
>>
>> [1] https://issues.apache.org/jira/browse/CALCITE-643
>>
>>
>>> On Apr 26, 2023, at 9:39 AM, Joachim Bloche <jb...@sbl.im> wrote:
>>>
>>> Hi,
>>>
>>> I'm discovering Calcite after a customer asked me to enhance a proof of concept they made with it.
>>>
>>> I could get most things to work as needed and am very impressed with the possibilities offered. But completely stuck on a critical point : I can't find any hint on how to manage authentication and authorization of users - sorry if information is available and I somehow missed it, but I did my best to research it.
>>>
>>> The customer needs to allow access only to certain schemas or tables (or columns as a bonus) based on user role.
>>>
>>> Do you know of any standard way to implement this ? Ideally I would need to implement it as low as possible in the stack as I'd like to use the same authorization process for both front-end users and users connecting through the Avatica JDBC driver.
>>>
>>> With my still limited knowledge of Calcite, the only "off the shelf" solution I could find is to create one Calcite model per role and start one Avatica server per model. Obviously I'm not very proud of this one as it's not really scalable nor elegant and there has to be a better solution.
>>>
>>> Any hint to point me in the right direction would be hugely appreciated as I would need the same for future projects.
>>>
>>>
>>>
>>> Of course if some development is needed to implement this in Calcite this could be an opportunity to contribute to the project.
>>>
>>>
>>>
>>> Many thanks in advance and best regards,
>>>
>>>
>>>
>>> Joachim
>>>
>>>
>>
RE: Authentication and authorizations in Calcite
Posted by Joachim Bloche <jb...@sbl.im>.
Thank you Julian and Stamatis for taking the time to answer this, it gives me a clear idea of the current status and the path forward.
I'll explain this to my customer and will let you know if we can invest time to work on implementing authorizations in Calcite - that would be great !
Best regards,
Joachim
-----Message d'origine-----
De : Julian Hyde <jh...@gmail.com>
Envoyé : lundi 1 mai 2023 19:58
À : dev@calcite.apache.org
Objet : Re: Authentication and authorizations in Calcite
Thanks for digging these up, Stamatis.
I have logged https://issues.apache.org/jira/browse/CALCITE-5681 for DDL (GRANT and REVOKE commands).
Contributions welcome.
Julian
> On Apr 29, 2023, at 6:53 AM, Stamatis Zampetakis <za...@gmail.com> wrote:
>
> Following up on the authorization part lots of things can be achieved
> through the use of views. Views can be used to restrict the columns
> and rows that are visible to certain users and it is a common way of
> handling permissions.
>
> Here also two other JIRA tickets with discussion around this topic:
> https://issues.apache.org/jira/browse/CALCITE-2194
> https://issues.apache.org/jira/browse/CALCITE-5292
>
> Best,
> Stamatis
>
>
>
> On Sat, Apr 29, 2023 at 2:11 AM Julian Hyde <jh...@gmail.com> wrote:
>>
>> I think Calcite should stay out of the authentication business. The
>> container (not Calcite) should authenticate users and convert them to
>> security principals that Calcite knows about. (Avatica does
>> authentication [1] but it just delegates to a provider.)
>>
>> Regarding authorization. I support adding a grants system to Calcite. Grants could be created via DDL (GRANT, REVOKE commands) or via APIs (like interface Schema) and the validator should enforce them. E.g. principal1 can see table1 but is not allowed to see its columns column2 and column3.
>>
>> If you’re interested please log Jira case(s).
>>
>> Julian
>>
>> [1] https://issues.apache.org/jira/browse/CALCITE-643
>>
>>
>>> On Apr 26, 2023, at 9:39 AM, Joachim Bloche <jb...@sbl.im> wrote:
>>>
>>> Hi,
>>>
>>> I'm discovering Calcite after a customer asked me to enhance a proof of concept they made with it.
>>>
>>> I could get most things to work as needed and am very impressed with the possibilities offered. But completely stuck on a critical point : I can't find any hint on how to manage authentication and authorization of users - sorry if information is available and I somehow missed it, but I did my best to research it.
>>>
>>> The customer needs to allow access only to certain schemas or tables (or columns as a bonus) based on user role.
>>>
>>> Do you know of any standard way to implement this ? Ideally I would need to implement it as low as possible in the stack as I'd like to use the same authorization process for both front-end users and users connecting through the Avatica JDBC driver.
>>>
>>> With my still limited knowledge of Calcite, the only "off the shelf" solution I could find is to create one Calcite model per role and start one Avatica server per model. Obviously I'm not very proud of this one as it's not really scalable nor elegant and there has to be a better solution.
>>>
>>> Any hint to point me in the right direction would be hugely appreciated as I would need the same for future projects.
>>>
>>>
>>>
>>> Of course if some development is needed to implement this in Calcite this could be an opportunity to contribute to the project.
>>>
>>>
>>>
>>> Many thanks in advance and best regards,
>>>
>>>
>>>
>>> Joachim
>>>
>>>
>>