Authentication
By default, InterDiode authenticates users with standard passwords. However, user authentication can be delegated to the reverse proxy, allowing single sign-on solutions like Keycloak, Authentik, Shibboleth, or Kerberos/GSSAPI.
Users can also define a API key for accessing to repositories that are not made publicly available.
Password authentication
As said before, users are by default locally created and authenticated by their password. Moreover, the first created user is granted administrator rights.
Users can create their own account (otherwise, only a superuser can create new accounts):
[auth]
create_users = true
HTTP basic authentication is enabled by default, but you can easily disable it:
[auth]
allow_basic_auth = true
If you want to create another administrator, you can use the command line (or use the web interface to promote a regular user):
interdiode-ctl createsuperuser
Finally, you can change any password with another command:
interdiode-ctl changepassword [username]
Token authentication
To access cloned repositories that are kept private, users can define tokens (or API keys). This authentication method is limited to mirrored API (like downloading packages) and does not allow to edit sources or user passwords. The user can create tokens with limited privileges or limited to a few IP addresses. Each token is tied to a source and cannot be used with another source.
Reverse-proxy authentication
You reverse proxy (Apache or Nginx) can authenticate users and put the username in a HTTP header (often
REMOTE_USER).
Since the header is set by the reverse proxy and not by the InterDiode server itself, this HTTP header is renamed to
HTTP_REMOTE_USER.
Reverse proxies can handle many authentication methods, like Kerberos/GSSAPI, LDAP, Shibbolet, and so on.
The user is automatically created in InterDiode on its first connection (you can even automatically add him to
several groups) if create_user is true.
Some pages and links may be anonymously accessible (by command-line tools like package managers), so you should not require authentication
on every page but only on /v1/login/ (or /v1/login/ and / to provide
transparent authentication).
[auth]
create_users = true
remote_user_groups = Users
remote_user_header = HTTP_REMOTE_USER
If this method does not work, try another header name (without dash - nor underscore _).
You can disable the local password database if users should be only authenticated by the reverse proxy:
[auth]
local_users = true