I've looked through the PR more closely, trying to understand the use case, and there are some Java-specific things going on (left a comment). Please keep in mind that we have thin clients in Python, Node.js, C++, C#. The protocol must be language-agnostic. If we add some features there, let's make sure they are usable from anywhere.
On Wed, Jan 22, 2020 at 9:21 PM Pavel Tupitsyn <ptupit...@apache.org> wrote: > 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 >> >
