[ 
https://issues.apache.org/jira/browse/CASSANDRA-20000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892816#comment-17892816
 ] 

Stefan Miklosovic commented on CASSANDRA-20000:
-----------------------------------------------

The only custom implementation I know of which extends CassandraRoleManager is 
our LDAPCassandraRoleManager. We do not have any need for this table as of now 
but it is interesting to contemplate about that. I am not sure yet what type of 
options we would need to put into the proposed table, I see an issue like this 
(2) where people would like to automatically grant roles to an ldap role based 
on what group that ldap role belongs to. If an ldap role belongs to group A (in 
LDAP context) and I want that LDAP role (in Cassandra context) to be 
automatically granted role B, then I guess I would need a table which tracks 
the mapping. The workflow would be like:

1) parse the group a LDAP role belongs to
2) look into somewhere to see if there is a mapping of that group to a 
Cassandra role
3) ensure that respective Cassandra role is granted a respective LDAP user (in 
Cassandra context).

I am not sure how this custom table would be needed in this situation.

However, there is this (3) where [~mck] proposes to use OPTIONS for storing 
additional information needed for rate limiting. I think that he looked into 
spec and saw OPTIONS so he used them without know this is actually not 
implemented yet. I think that if CASSANDRA-19734 is going to be done (I plan to 
work on that in the future) then having this already in would make our life 
easier so in that regard I am +1 on delivering this.

(1) https://github.com/instaclustr/cassandra-ldap
(2) https://github.com/instaclustr/cassandra-ldap/issues/48
(3) https://issues.apache.org/jira/browse/CASSANDRA-19734

> Add support for Role's OPTIONS
> ------------------------------
>
>                 Key: CASSANDRA-20000
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-20000
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL/Semantics, Feature/Authorization
>            Reporter: Tiago L. Alves
>            Assignee: Tiago L. Alves
>            Priority: Normal
>             Fix For: 5.x
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> The Cassandra Query Language 
> [https://cassandra.apache.org/doc/stable/cassandra/cql/security.html] / 
> [https://cassandra.apache.org/doc/5.0/cassandra/developing/cql/security.html] 
> specify that a role can have custom options defined as literal map.
> The documentation shows a valid example of these custom options:
> {{CREATE ROLE carlos WITH OPTIONS = \{ 'custom_option1' : 'option1_value', 
> 'custom_option2' : 99 };  }}
> However, the storage/retrieval of such custom options has not been 
> implemented in Cassandra. See for instance, 
> [https://github.com/apache/cassandra/blob/18960d6e3443bf002ef4f46c7f0e1f2ee99734e1/src/java/org/apache/cassandra/auth/CassandraRoleManager.java#L393-L396]
> Storing custom options per role could have multiple usages, for instance, it 
> could allow admins to specify fine-grain permissions that can be interpreted 
> by custom authenticator/authorizer.
> The goal of this task is to add support for Role custom options, by storing 
> them in an additional table called {{role_options}} in the {{system_auth}} 
> keyspace.
> Creating a role with options should write the information in both the 
> {{roles}} and the {{role_options}} tables. Creating a role with no options or 
> having an empty map of options should not write any information in the 
> {{role_options}} table.
> Altering a role should behave as follows when executing an {{ALTER ROLE}} 
> statement:
>  * without specifying {{{}OPTIONS{}}}: no changes should be done in the 
> {{role_options}} table. 
>  * specifying {{OPTIONS}} altering a role with no previous custom options: we 
> should insert the custom options in the {{role_options}} table.
>  * specifying {{OPTIONS}} altering a role with previous custom options: we 
> should replace the existent custom options
>  * in the {{role_options}} table.
> Dropping a role should drop information in both {{roles}} and 
> {{{}role_options{}}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to