ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Username/password authentication for thin clients
Date Mon, 15 Jan 2018 19:32:26 GMT
The overall proposal sounds simple and reasonable to me. However, I would suggest us to consider
requirements of REST, Web Console and scripts that needs to be adopted too.

Alexey K., Andrey N., as Web Console maintainers please chime in.

Vladimir, do you think simple password based authentication and SQL commands for user management
will be ready by 2.5 release?

—
Denis

> On Jan 15, 2018, at 12:19 AM, Vladimir Ozerov <vozerov@gridgain.com> wrote:
> 
> Igniters,
> 
> Current Ignite has no means for user authentication and authorization. I
> believe this is a big flaw in the product and we should start working on
> it. As a first step I would like to propose to add simple username/password
> authentication for our thin clients ("thin", JDBC, ODBC).
> 
> Proposed design:
> 1) Define hidden persistent cache for user credentials
> 2) Credentials will be stored in a form of [username + hash] [1]
> 3) Default superuser ignite/ignite will be defined by default. This is the
> only user which can create other users
> 4) Authentication will be disabled by default to let users migrate from
> previous versions easily
> 5) Clients will optionally pass username and password to the cluster during
> handshake phase.
> 6) Password will be delivered in a *plain form*, because otherwise clients
> will have to implement complex hashing logic on their own. SSL will be used
> to protect passwords.
> 7) Create SQL commands for user management (CREATE USER, ALTER USER, DROP
> USER)
> 8) May be we will also create native public API.
> 
> This will be our foundation for further security enhancements, such as:
> - Node authentication
> - Authorization mechanics
> - Various no-password authentication techniques (e.g. certificate-based)
> 
> Please share your thoughts on proposed design.
> 
> Vladimir.
> 
> [1] Exact cryptographic function is to be defined.


Mime
View raw message