Folks, I did the initial review for a contribution. The ultimate goal is to have the possibility to pass user defined attribute-value pairs in all types of clients, same as user attributes in java configuration [1]. Later they can be used on server side for various things, for example in authentication.
The problem from my understanding is related to pass these attributes reliably in multi-platform way. As Pavel Tupitsyn suggested the protocol must be language-agnostic. Probably we use binary marshaller with compactfooter=false (or language specific implementation of binary marshaller) to pack attributes on client side to byte[] and later unpack them on server side. Thoughts ? [1] org.apache.ignite.configuration.IgniteConfiguration#setUserAttributes ср, 22 янв. 2020 г. в 21:39, Pavel Tupitsyn <ptupit...@apache.org>: > 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 > >> > > > -- Best regards, Alexei Scherbakov
