The approach with UserAttributes map looks dirty to me and raises questions:
- Why is UserAttributes property related to authentication? - UserAttributes name implies that users can put there anything they want, but what for? What are those additional use cases? I think we should focus on a specific problem at hand and avoid unnecessary future-proofing. What are current and potential future custom authenticators and what kind of data do they need? On Wed, Jan 22, 2020 at 6:28 PM Nikita Amelchev <nsamelc...@gmail.com> wrote: > I think we should add this. It will provide an extra level of security. > This approach is used in many products, for example in AWS (MFA). [1] > > [1] > https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#multi-factor-authentication > > ср, 22 янв. 2020 г. в 18:13, Andrey Kuznetsov <stku...@gmail.com>: > > > > Hi, Pavel! > > > > Sometimes single authentication factor is not enough. Attributes proposed > > allow to add extra factors flexibly. > > > > ср, 22 янв. 2020 г., 17:39 Pavel Tupitsyn <ptupit...@apache.org>: > > > > > Token can be sent instead of a password (like git works with GitHub > > > tokens). > > > > > > For now I don't see a reason to include attributes into the handshake > > > message. > > > > > > On Wed, Jan 22, 2020 at 5:32 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > > > > > > wrote: > > > > > > > Hello! > > > > > > > > One does not send security certificate as attribute. The only way to > > > obtain > > > > peer security certificate is to ask SSL engine to provide it. > > > > > > > > Nevertheless, I can see how it can be useful with e.g. Kerberos, > which is > > > > token-based IIRC. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > ср, 22 янв. 2020 г. в 17:20, Dmitrii Ryabov <somefire...@gmail.com>: > > > > > > > > > This map is something like user object from `SecurityCredentials`. > > > > > Sometimes login and password are not enough for security checks. > For > > > > > example, we can send security certificate and validate it inside > > > > > authenticator. > > > > > > > > > > ср, 22 янв. 2020 г., 17:16 Igor Sapego <isap...@apache.org>: > > > > > > > > > > > Hi Dmitrii, > > > > > > > > > > > > Can you please explain your use case? > > > > > > I'm not sure I'm getting what is the motivation of this change. > > > > > > > > > > > > Best Regards, > > > > > > Igor > > > > > > > > > > > > > > > > > > On Wed, Jan 22, 2020 at 5:11 PM Pavel Tupitsyn < > ptupit...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi Dmitrii, > > > > > > > > > > > > > > Honestly, I could not grasp the problem, can you explain it in > more > > > > > > detail? > > > > > > > What do we solve by adding a map with arbitrary stuff to the > client > > > > > > > protocol handshake? > > > > > > > > > > > > > > On Wed, Jan 22, 2020 at 5:02 PM Dmitrii Ryabov < > > > > somefire...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Hello, Igniters! > > > > > > > > > > > > > > > > I want to add the possibility of sending user defined > attributes > > > > from > > > > > > > thin > > > > > > > > clients. And check them inside custom authenticator during > > > > handshake > > > > > > [1]. > > > > > > > > > > > > > > > > There is an issue in hardcoded binary writer for JDBC and > > > > > > `IgniteClient`. > > > > > > > > This writer searches for a classes in the JDK and > > > > > > > > META-INF/classnames.properties, and tries to sync notdeclared > > > > classes > > > > > > > with > > > > > > > > cluster. But fails because current classloading uses > discovery. > > > > > > > > > > > > > > > > I'd like to keep this writer and allow only primitive types > and > > > > > > `String` > > > > > > > > for user attributes to prevent unexpected fails. I think it > is > > > > better > > > > > > > than > > > > > > > > changing writer to one with heavy classloading. > > > > > > > > > > > > > > > > Is it ok to restrict thin attributes to primitives and > 'String'? > > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12049 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Best wishes, > Amelchev Nikita >
