Re: Internal Security - Authentication & Authorization

[Sam Tunnicliffe]

>
> Here is what I have pieced together. Please let me know if I am on the
> right track.


You're more or less right regarding the built in
authenticator/authorizer/role manager (which are usually referred to as
"internal" as they store their data in Cassandra tables). One important
thing to note is that using the default superuser credentials (i.e. logging
in as 'cassandra') will make these reads happen at QUORUM, not LOCAL_ONE,
which is one of the reasons you shouldn't use those credentials
after initial setup.

There are 2 settings which govern the lifetime of cached auth data. Once an
item has been cached, it becomes eligible for refresh after the update
interval has passed. A get from the cache will trigger this refresh, which
happens in the background and while it's running, the old (maybe stale)
entry is served from the cache. When the validity period expires for a
cache entry, it is removed from the cache and subsequent reads trigger a
blocking fetch from storage.

There is further detail in the docs here:
http://cassandra.apache.org/doc/latest/operating/security.html

 If NOT EXISTS will use SERIAL consistency


This isn't actually true. Because internal storage is just one
implementation of role/user management, it doesn't rely on LWT. Instead,
the configured role manager is consulted before executing the statement,
which is similar to how IF NOT EXISTS in schema updates work.


On Tue, Mar 14, 2017 at 11:44 PM, Jai Bheemsen Rao Dhanwada <
jaibheem...@gmail.com> wrote:

> I have similar question. when we create users or roles what is the
> consistency level used?
>
> I know, If NOT EXISTS will use SERIAL consistency. what consistency will
> be used if just use CREATE USER ?
>
> On Mon, Mar 13, 2017 at 7:09 PM, Jacob Shadix 
> wrote:
>
>> I'm looking for a deeper understanding of how Cassandra interacts with
>> the system_auth keyspace to authenticate/authorize users.
>>
>> Here is what I have pieced together. Please let me know if I am on the
>> right track.
>>
>> A user attempts to connect to Cassandra. Cassandra checks against
>> system_auth for that user @ LOCAL_ONE - - If the user exists, a connection
>> is established. When CQL is executed, C* again checks system_auth for that
>> user @ LOCAL_ONE to determine if it has the correct privileges to perform
>> the CQL. If so, it executes the CQL and the permissions are stored in a
>> cache. During the cache validity timeframe, future requests for ANY user
>> stored in the cache do not require a lookup against system_auth. After the
>> cache validity runs out, any new requests will require a lookup against
>> system_auth.
>>
>> -- Jacob Shadix
>>
>
>

Re: Internal Security - Authentication & Authorization

[kurt greaves]

Jacob, seems you are on the right track however my understanding is that
only the user that was auth'd has their permissions/roles/creds cached.

Also. Cassandra will query at QUORUM for the "cassandra" user, and at
LOCAL_ONE for *all* other users. This is the same for creating users/roles.

Re: Internal Security - Authentication & Authorization

[Jai Bheemsen Rao Dhanwada]

I have similar question. when we create users or roles what is the
consistency level used?

I know, If NOT EXISTS will use SERIAL consistency. what consistency will be
used if just use CREATE USER ?

On Mon, Mar 13, 2017 at 7:09 PM, Jacob Shadix  wrote:

> I'm looking for a deeper understanding of how Cassandra interacts with the
> system_auth keyspace to authenticate/authorize users.
>
> Here is what I have pieced together. Please let me know if I am on the
> right track.
>
> A user attempts to connect to Cassandra. Cassandra checks against
> system_auth for that user @ LOCAL_ONE - - If the user exists, a connection
> is established. When CQL is executed, C* again checks system_auth for that
> user @ LOCAL_ONE to determine if it has the correct privileges to perform
> the CQL. If so, it executes the CQL and the permissions are stored in a
> cache. During the cache validity timeframe, future requests for ANY user
> stored in the cache do not require a lookup against system_auth. After the
> cache validity runs out, any new requests will require a lookup against
> system_auth.
>
> -- Jacob Shadix
>