This page explains the authentication process with the auth-controller.

Authenticate

As described in our swagger instance, we need a username and a password in order to log a user in . This is can be done in the request body or as request parameter. A strong advise is to use the request body.

{
  "username": "gauss",
  "password": "password"
}

We provide different kind of user realms.

1. In Memory: set which only exists inside the application memory. Editing and database operations aren't possible

2. Local: User can be created locally. They have their own password (BCRYPT Hashed) which is used for authentication

3. LDAP: Users are provided by an external provider. The connection is established via the LDAP protocol. On the first login users will be cached to our own database. They won't have password objects trying to change password via any controller won't have any effect. Changing settings (which are stored in the local database) are possible.

On authentication attempts, these three realms are checked for the username in the listed order. Starting with "In Memory". If a desired username is found in a specific realm, the process stops and the authentication is finished.

Conclusion: Local users can override LDAP users.

Desired Realm - WORK IN PROGRESS. Not supported yet.

{
  "username": "gauss@REALM",
  "password": "password"
}

With a realm modifier a specific realm can be queried.

JWT

The JWT token is returned inside the response header followed by status code 200.

Example Header:

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpc3MiOiJzc ....
cache-control: no-cache, no-store, max-age=0, must-revalidate 
connection: keep-alive  
content-length: 0  
date: Wed, 08 Apr 2020 10:09:50 GMT  
expires: 0  
keep-alive: timeout=60  
pragma: no-cache  
vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers  x-content-type-options: nosniff  x-frame-options: DENY  x-xss-protection: 1; mode=block 

Procedurals

If a service has it's own rights management or needs to know the login state of the user for other reasons, use the "verfiy" method from the AuthenticationController to verify the login state of the user in the backend.

Example steps: Assume a REST project with has a client and a backend which needs to use SparkyService as authentication provider.

1. Client authenticate against SparkyService.
2. Client sends token to the backend.
3. Backend uses the verify method to check if the client is successfully authenticated.
4. Go ahead. At this point the backend knows that the user is logged in.

Proxy/Routing

When using the proxy of the services, the Authorization-Proxy header must be used for authentication. The Authorization header is reserved for the underlying service to be routed to. For more information see Proxy