[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326113#comment-17326113
]
Alexey Zotov commented on CASSANDRA-16404:
------------------------------------------
[~blerer] [~sumanth.pasupuleti]
Thanks for the feedback! I've addressed your comments. I'll push tests
refactoring into a separate PR.
Basically I'm done with the changes I wanted to make. Could you, please, review
the changes.
I read about [roles
hierarchy|https://www.datastax.com/blog/role-based-access-control-cassandra]
and I feel it would be complicated enough to support them. Basically the
problem is related to the fact that we cache permissions (permissions, network
permissions, jmx permissions) after we calculate them using roles hierarchy.
Permissions invalidation for a user (a role with "login" attribute = true)
works fine with the current changes. However, permissions invalidation for a
group role (a role that is granted to other roles) would require tracing the
hierarchy in a reverse direction and invalidating the whole affected hierarchy
from cache. It is theoretically possible, but in practice there is one
directional relation between roles ({{RolesCache extends
AuthCache<RoleResource, Set<Role>>}}). I can take a look to this part further
if you believe that it needs to be address at this point, also I'd be glad to
hear a piece of advice on the best way to tackle the hierarchical invalidation.
> Provide a nodetool way of invalidating auth caches
> --------------------------------------------------
>
> Key: CASSANDRA-16404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16404
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
> Reporter: Sumanth Pasupuleti
> Assignee: Alexey Zotov
> Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We currently have nodetool commands to invalidate certain caches like
> KeyCache, RowCache and CounterCache.
> Being able to invalidate auth caches as well can come in handy in situations
> where, critical backend auth changes may need to be in effect right away for
> all the connections, especially in configurations where cache validity is
> chosen to be for a longer duration. An example can be that an authenticated
> user "User1" is no longer authorized to access a table resource "table1" and
> it is vital that this change is reflected right away, without having to wait
> for cache expiry/refresh to trigger.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
