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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >>> >>
