Re: [Discuss] CEP-24 Password validation and generation

["Miklosovic, Stefan" <St...@netapp.com>]

Thanks Andrés.

After careful consideration, I think it would be better if the initial implementation dropped the validation of a password against the previous ones so people can not re-use them too often. This feature would bring additional complexity and new table in system_auth keyspace. It is good we know how we could do that if somebody really wants that to happen. I just do not find it absolutely necessary at this time. Simple validation / generation with related CQL commands should be enough at the moment and we can expand that as we go.

I will reflect this into the CEP and I will initiate the vote soon. It is around 3 weeks since I posted this and that seems to be quite a long time for everybody being able to raise their questions if they had any.

This seems to be quite straightforward CEP anyway, I wanted to put everything together as that topic is rather broad with all the details involved and CEP seemed to be a good way how to cement that.


________________________________________
From: Andrés de la Peña <ad...@apache.org>
Sent: Friday, September 23, 2022 13:36
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CEP-24 Password validation and generation

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.



I think that custom, pluggable type of guardrail will be a great addition to the framework.

The first guardrails prototype included a factory of guardrails that was able to provide different guardrail instances depending on the specified class and client state. That was discarded during review in favour of a pluggable provider of guardrail configurations, so the guardrail instances are always the same but the source of configuration can be customized. That allows to provide different configurations for different users with minimal hassle. Although that works for most of the guardrails, it doesn't give the kind of flexibility than the ability to plug custom guardrail implementations does.

I think that the proposed approach for making specific guardrail implementations pluggable allows us to keep the simplicity of the current approach while also giving us flexibility for particular cases like password validation. The generic CustomGuardrail that will be added to the framework should ease (and standardize!) validation pluggability, so I think it can be useful in the future.

On Mon, 19 Sept 2022 at 12:27, Miklosovic, Stefan <St...@netapp.com>> wrote:
Hi list,

together with my colleague Jackson Fleming we put together CEP-24 about password validation and password generation in Cassandra.

https://cwiki.apache.org/confluence/x/QoueDQ

We are looking forward to discuss this CEP with you in depth.

The outcome of this thread would be to sort out any issues / concerns you have so we might eventually vote and implement that in upstream if our contribution is found to be useful.

There is a reference implementation provided we would like to build our solution on top.

Regards

Stefan Miklosovic