Hi folks!
The change is ready for review in GitHub:
https://github.com/apache/knox/pull/826
Thanks, @Attilla Magyar for reviewing it already.
I'd like to ask for at least one more from someone.
Thanks!
On Thu, Nov 30, 2023 at 12:03 PM Sandor Molnar wrote:
> FYI: https://issues.apache.org/jira/
FYI: https://issues.apache.org/jira/browse/KNOX-2990
On Thu, Nov 30, 2023 at 9:05 AM Sandor Molnar wrote:
> Hello folks!
>
> After an offline discussion with Larry, we agreed on the following (as an
> extension to the action plan I listed above):
> - the migration tool will be run automatically
Hello folks!
After an offline discussion with Larry, we agreed on the following (as an
extension to the action plan I listed above):
- the migration tool will be run automatically when the Knox Gateway
starts, and it will run on the main thread (i.e. not in the background).
- there will be a confi
If we can determine whether there is already an alias based TSS in place
and continue to use that for upgrades but derby for new clusters, I would
be in favor of that.
On whether to enable encryption, if we are only storing a hash of the
passcode token then that should be okay.
The persistence shou
Hi folks!
Let me try to summarize what we have so far:
1. we are all in favor of removing the JournalBased and Zookeeper TSS
implementations
2. we all agreed that removing the AliasBasedTSS implementation requires
extra caution
3. Larry raised the following concerns
3.1 clear data storage in D
First and foremost, I'll echo the comments about deprecation. IMO, we must
deprecate these implementations in a release before completely removing
them in a subsequent release.
I agree that the ZK and Journal implementations should be deprecated for
the reasons stated.
Concerning replacing the al
Agreed!
On Tue, Nov 14, 2023 at 7:15 AM Sandor Molnar
wrote:
> Thanks, Sandeep for your insights too!
>
> To be honest, I would be surprised if someone used the JournalBased or the
> ZK TokenStateService implementations for storing tokens (even in the wild).
> In the case of AliasBasedTSS, it mi
Thanks, Sandeep for your insights too!
To be honest, I would be surprised if someone used the JournalBased or the
ZK TokenStateService implementations for storing tokens (even in the wild).
In the case of AliasBasedTSS, it might be true. That's why I suggested that
we could write a small KNOX CLI
Thanks, Larry, and Attila for your above comments.
I'm trying to answer the questions you raised Larry:
1. I believe the data is stored in the clear in files in the directory - is
this true?
As Attila pointed out, Derby supports data encryption in a quite easy way.
Currently, we use Debry 10.14 s
Thank you for starting the thread Sandor. You bring up valid points and
pain that we had to go through with these implementations :)
I am in favor of removing these as well. My concern is around folks
currently using any of these impls. Should we deprecate it this release
(but keep the support and
I support this change. I'd like to add that derby also supports DB level
encryption, using DES or triple DES.
It can be specified the following way:
jdbc:derby:encryptionDB1;create=true;dataEncryption=true;
bootPassword=clo760uds2caPe
On Mon, Nov 13, 2023 at 4:59 PM larry mccay wrote:
>
I am in favor of this in general.
My only concern is the alias based one.
This is the default implementation for token based authentication flows and
is possibly more secure than a derby based implementation.
Let's begin with some questions about the use of derby:
1. I believe the data is stored
Hello folks!
I'm starting this thread because I am convinced we should remove the
following TokenStateService implementations:
- AliasBasedtokenStateService
- ZookeeperTokenStateService
- JournalBasedTokenStateService
The reason behind this idea for the last two implementations in the above
list
13 matches
Mail list logo
