ID | IEP-105106 | ||||||||
Author | |||||||||
Sponsor | |||||||||
Created |
| ||||||||
Status |
|
Table of Contents |
---|
This document describes the mechanisms for user authentication on the side of the Ignite cluster and provides different mechanisms of authentication for AI3 and GG9 specifically.
The main goal of authentication will be to set restrictions on the use of various functions of the Ignite through various public APIs (REST API, CLI, clients, etc) and restrict unwanted access to various parts of the cluster.
As a base solution Apache Ignite 3 will have a basic authentication mechanism. This is cluster side configuration and it should be provided on the cluster initialization step.
...
After cluster initialization login and password may be changed in cluster configuration but it will be required previous login and password.
Authentication information will be stored to cluster distributed configuration. Currently we have no any configuration data compression or ciphers and we store authentication info as is in plain format. But we should mark this properties as secrets and any read of configuration anyway should mask this properties.
Users can enable (disable) authentication and change credentials in runtime using the CLI command cluster config set
Code Block |
---|
cluster config update "security": {
"rest": {
"auth": {
"enabled": true,
"basic": {
"login": "string",
"password": "string"
}
}
}
} |
...
In case when authentication fails, CLI should map a REST response with a failed reason and show to the user formatted message with details. This mechanism already exist and using in different situations in CLI.
Also, we need to make some changes on the server side:
See https://guides.micronaut.io/latest/micronaut-security-basicauth-gradle-java.html.
Code Block |
---|
"security": {
"rest": {
"auth": {
"enabled": true,
"basic": {
"login": "string",
"password": "string"
}
}
}
} |
ClientInboundMessageHandler handler should
...
Proposed solution complicates clients configuration and functionality - they need to be configured for each different auth provider and include the functionality of retrieving the access token from the provider.
This could be simplified by implementing the authentication service. In this case the user will get the access token from the Control Center and will pass it to the node, which will verify it in the auth service.
CLI may have special command ignite cluster openid connect which will open a browser with Control Center page where user may specify a 3rd party connector and authenticate via 3rd party cloud provider. After the authentication process will be finished response can be catched via CLI and CC token may automatically stored to CLI configuration.
This is technically not easy to achieve, because the OpenId pipeline requires a callback of success authentication in the form of URL to redirect and it should be mapped to CLI somehow. This is possible to achieve with several options
...
Also, we need to make some changes on the server side:
See https://guides.micronaut.io/latest/micronaut-security-basicauth-gradle-java.html.
Code Block |
---|
"security": {
"rest": {
"auth": {
"enabled": true,
"basic": {
"login": "string",
"password": "string"
}
}
}
} |
[IGNITE-19597] Ignite3 Basic Authentication Support - ASF JIRA (apache.org)