
The GSSAPI authenticator documentation now has a section on how to set up the environment.
77 lines
2.9 KiB
Markdown
77 lines
2.9 KiB
Markdown
# GSSAPI Client Authenticator
|
|
|
|
GSSAPI is an authentication protocol that is commonly implemented with
|
|
Kerberos on Unix or Active Directory on Windows. This document describes
|
|
the GSSAPI authentication in MaxScale.
|
|
|
|
The _GSSAPIAuth_ module implements the client side authentication and the
|
|
_GSSAPIBackendAuth_ module implements the backend authentication.
|
|
|
|
## Preparing the GSSAPI system
|
|
|
|
For Unix systems, the usual GSSAPI implementation is Kerberos. This is a short
|
|
guide on how to set up Kerberos for MaxScale.
|
|
|
|
The first step is to create a new principal for MaxScale. This can be done with
|
|
the _kadmin_ or _kadmin.local_ tools.
|
|
|
|
```
|
|
kadmin.local -q "addprinc -nokey mariadb/example.com@EXAMPLE.COM"
|
|
```
|
|
|
|
The _-nokey_ option will make the principal a passwordless one. This allows the
|
|
_maxscale_ user to acquire a ticket for it without a password being prompted.
|
|
|
|
The next step is to export this principal into the Kerberos keytab file.
|
|
|
|
```
|
|
kadmin.local -q "ktadd -k /etc/krb5.keytab -norandkey mariadb/example.com@EXAMPLE.COM"
|
|
```
|
|
|
|
This adds the _mariadb/example.com@EXAMPLE.COM_ principal into the keytab
|
|
file. The `-norandkey` option tells that the password we defined earlier,
|
|
i.e. no password at all, should be used instead of a random password.
|
|
|
|
The MariaDB documentation for the [GSSAPI Authentication Plugin](https://mariadb.com/kb/en/mariadb/gssapi-authentication-plugin/)
|
|
is a good example on how to set up a new principal for the MariaDB server.
|
|
|
|
## Authenticator options
|
|
|
|
The client side GSSAPIAuth authenticator supports one option, the service
|
|
principal name that MaxScale sends to the client. The backend authenticator
|
|
module has no options.
|
|
|
|
### `principal_name`
|
|
|
|
The service principal name to send to the client. This parameter is a
|
|
string parameter which is used by the client to request the token.
|
|
|
|
The default value for this option is _mariadb/localhost.localdomain_.
|
|
|
|
The parameter must be a valid GSSAPI principal name
|
|
e.g. `styx/pluto@EXAMPLE.COM`. The principal name can also be defined
|
|
without the realm part in which case the default realm will be used.
|
|
|
|
## Implementation details
|
|
|
|
Read the [Authentication Modules](Authentication-Modules.md) document for more
|
|
details on how authentication modules work in MaxScale.
|
|
|
|
### GSSAPI authentication
|
|
|
|
The GSSAPI plugin authentication starts when the database server sends the
|
|
service principal name in the AuthSwitchRequest packet. The principal name will
|
|
usually be in the form `service@REALM.COM`.
|
|
|
|
The client will then request a token for this service from the GSSAPI server and
|
|
send the token to the database server. The database server will verify the
|
|
authenticity of the token by contacting the GSSAPI server and if the token is
|
|
authentic, the server sends the final OK packet.
|
|
|
|
## Limitations
|
|
|
|
Client side GSSAPI authentication is only supported when the backend
|
|
connections use GSSAPI authentication.
|
|
|
|
See the [Limitations](../About/Limitations.md) document for more details.
|