User Authentication (simple username/password login)

[janniclas]

Feature
The current Landingpage should be replaced by a basic login mask in which the user can provide a username and password.

Data flow scheme for Authentication

1. The username & password should be send to a (new) authenticate endpoint of the scala play webserver.
2. On the scala play webserver a component token is added to the request and it is forwarded to the authorization endpoint of the instance registry.
3. The ir responds with a user token, which is send as a response to the client
4. The client stores the user token and appends it to every request as needed

@johannesduesing what is the lifetime of the user token and do you have a plan in place to refresh the user token?

@Ayybeeshafi will handle the extensions needed on the server side, while I will make the necessary extensions in the api service of the frontend.
@ishwaryaPaderborn if you like you could provide a design for a login page (do we already have something like this in place?)

[janniclas]

In the currently proposed solution the endpoints of the management webserver would be protected with the user token and this server would do the request filtering and only forward the valid requests to the instance registry.
An alternative would be to append the user token to the requests to the registry and let it handle the validation there.
Currently, I would suggest to let the management server do the validation of the user tokens.
In a long run, when we start to include different user roles, it will most likely be a good idea to include a standalone authorization service for the overall authentication stuff and role management.

As our security expert, @bhermann do you have anything to add or further suggestions to this proposal?

[Ayybeeshafi]

I have implemented a method that invocates user/authenticate endpoint. It sends two headers(Basic Authentication and Delphi management JWT token). As a response IR returns a token.

Till now there is no method to check my side of the code. Although, if two headers are sent via Postman in a POST request the IR successfully returns a token as in the following screenshot.

Furthermore, there are some prerequisites for IR to process the user/authenticate request.

• Your system must have mysql installed and running.
• You need to create a database for user authentication on your local machine (e.g. userAuth)
• in Configuration.scala file of IR. Change useInMemoryAuthDB = false and add DB name along with username and password of your mysql.

[janniclas]

hey @Ayybeeshafi thx for your work, the code looks good so far (I've made a tiny comment to the last commit tho).

I would like to ask you to extend your authorization object with a method to validate the correctness of a given token.
As @johannesduesing explained to me the user token, which is created on the instance registry, can be validated on the backend of the management. The workflow, as described in this issue, would suggest that we include the user token in every request from the frontend to the backend of the management. The token can then be checked in the management and only the valid requests will be forwarded to the instance registry.
The validation could be implemented in the authorization object you designed. I would expect this method to take a token as input (which would be included in the authorization header of each request), validates the token and returns the result of the validation check.
If the check was successfull the existing code in the instance registry controller would be executed, else a 403 forbidden should be returned.

[johannesduesing]

The duration that a user token is valid for can be configured in the registry's configuration file, the default duration is 30 minutes. We do not have any mechanisms in place to deal with refreshing the token. What i would suggest is in the management backend to check whether a token is still valid, and if not redirect the user to the login page.

@janniclas what do you think of that ?

[janniclas]

hey @johannesduesing, I think for a first version of a basic user authorization this will be feasible, but in the long run we need some kind of refresh token to keep the user logged in.
I'm thinking about the use case in which we want to use the graph view of the management on a huge screen in front of @bhermann office to show the system's state at all times. This would only work for 30 minutes without a refresh token.

[ishwaryamamidi]

@janniclas I dont think we already have a 'Login' form. I think we just had a user profile created few months back. But because it was not of higher priority that time I removed it. hence, I will create a login form with required fields.

[janniclas]

This article describes the basic http interceptor method I'm implementing in our code right now. I plan to chain this with route guards to not only protect the api requests but also keep the user from navigating away from the login page without being logged in https://blog.angular-university.io/angular-jwt-authentication/