shellgraph

Authentication and roles

Users log in with LDAP or OIDC. Their groups give the role. The server has no local users.

Why no local users

The server keeps SSH private keys. Access to it must stop on the day that a person leaves the company. Most companies already control that in a directory or an identity provider, and local users in ShellGraph would be one more list that somebody must remember to clean. With LDAP or OIDC, you remove the person from the group. The access stops.

The server creates the user at the first login and updates it at each login after that. The Users page shows each user with the source, the role and the time of the last login.

Roles come from groups

At each login, the server reads the groups of the user:

  1. A member of SHELLGRAPH_ADMIN_GROUP gets the admin role.
  2. A member of SHELLGRAPH_VIEWER_GROUP gets the viewer role.
  3. A user in neither group cannot log in.

The server keeps the role in its database and checks it on each request, but it reads the groups only at login. A user that you remove from a group keeps the old role until the session ends. That is 12 hours at most.

LDAP login

  1. The server binds with the service account.
  2. The server finds the user with the user filter. The filter must find exactly one entry.
  3. The server binds as the user with the password. This checks the password. An empty password is always refused, because LDAP accepts an empty password as an anonymous bind.
  4. The server binds again with the service account and finds the groups of the user. The group name is the cn of the group.
  5. The server also reads the memberOf attribute of the user, if the directory has it.

The server escapes the login before it puts it in a filter, so a login such as *)(uid=* cannot change the filter.

OIDC login

  1. The user selects the OIDC button. The server sends the browser to the identity provider. The request uses PKCE (S256), a state and a nonce. The server keeps them in a signed cookie for 10 minutes.
  2. The user logs in to the identity provider. The provider sends the browser back to <public URL>/api/auth/oidc/callback.
  3. The server checks the state, gets the tokens from the provider, and verifies the ID token: the signature (with the public keys of the provider), the issuer, the audience, the expiry and the nonce.
  4. The groups come from the groups claim of the ID token. If the ID token does not have the claim, the server reads it from the userinfo endpoint.

The server accepts only asymmetric signatures (RS256, RS384, RS512, ES256, ES384, EdDSA). It refuses a token without a signature.