ara feat: rbac

Type of modification

[x] Breaking change
[ ] New Feature
[ ] Bug Fix
[ ] Chore (refactor, documentation, tests... all the changes with no impact on ARA functionalities.)

Changes description

Add possibility to manage right in ARA : developpement is based on https://docs.google.com/document/d/1T1By66dt1PqeDqSbWeJMtzmLDarKybOZWc9Y64QpxCE/edit Some right name are not exactly the one exposed in the document, if this version doesn't satisfy you, you can update name in enumeration (UserSecurityRole.java and MemberRole.java)

Technical description

When a user first connect it will be created in database with default role, the default role is configurable with property "ara.security.newUser.role", when this property is not set the defaut role for new User is PROJECT_OR_GROUP_CREATOR. Within first launch of the application with RBAC included, the first user that will connect to the application will be the first ADMIN and will have possibility to manage all ARA instance. In fact, when the application is upgrade to a version that have RBAC, users already have the URL of the application, and first login is not guarantee to be the desired User, so i have added a configuration to ensure that the correct user will have the ADMIN right. The configuration is "ara.security.admin.init.name" and must be set to the username entered in the OIDC/OAuth2 provider, when it's not set, the first user to login will be admin (no problem for new installation, because only installer has the url) To respond to a team demand, users in ARA are defined by two thing, the username in the OIDC/OAuth2 provider and the issuer of this provider, so same username in two different provider are different user in ARA.

To allow generic configuration for all projects API, the api PUT /api/projects/{id} is becomed /api/project/{code}. All Security configuration are centralized in CustomSecurity.java.

Some bahavior change:

Default project is now a User preference, each user can define it's own default project
The API that list all the project(GET /api/projects), list now only the project for which current user is member (An administrator can access to all project with there url, but doesn't see all of them by default. A new API as been created to list all existing project for administrator)

To avoid requesting same data at each page load, some function has been cached, because ehcache is already present in database sub module, i have added cache definition for functionnal cache in it's configuration file, it not seems to be the good place, but when i have tried to define it in it's own file, it enter in conflict with the Database one) The list of project by user is cached that's avoid 3 request in each page load. The role associated to an user by project is cached that's avoir 2 request in each page load. These caches lifecycle are manually managed, to see all case, you can refer to the test class CacheableTest.java

Some api has been added :

/api/projects/{code}/members/groups : GET : list all groups member of this project POST : add a group as member of this project (payload : {"name":"XXXX", "role" : "YYYY"})
/api/projects/{code}/members/groups/{groupName} GET : get member PATCH : update role of the member (payload : {"name":"XXXX", "role" : "YYYY"}) DELETE : delete member from this project
/api/projects/{code}/members/users : GET : list all users member of this project (only list users explicitly added on the project and not users inherited by groups) POST : add a user as member of this project (payload : {"name":"XXXX", "role" : "YYYY"})
/api/projects/{code}/members/users/{userName} : GET : get member PATCH : update role of the member (payload : {"name":"XXXX", "role" : "YYYY"}) DELETE : delete member from this project
/api/groups : GET : list all groups POST : create a group (payload : {"name":"XXXX"})
/api/groups/{groupName} : GET : get group DELETE : delete group (cannot be done if currently member of a project)
/api/groups/{groupName}/members : GET : list all users member of this group POST : add a user as member of this group (payload : {"name":"XXXX", "role" : "YYYY"})
/api/groups/{groupName}/members/{memberName} : GET : get member PATCH : update role of the member (payload : {"name":"XXXX", "role" : "YYYY"}) DELETE : delete member from this group
/api/admin/projects : GET : list all existing projects
/api/auditing/users-roles GET : list all users with their associated roles
/api/users GET : list all existing users
/api/users/{username} GET : get information about user POST : add role to user (user will be disconnected) (payload : {"role" : "YYYY"})
/api/users/{username}/{role} DELETE : delete role (user will be disconnected)

The API /api/user/details has becomed /api/users/current/details

Some javax.validation annotation were used in ARA code, but no implementation that treat these annotation was present. I have added the necessary dependency (spring-boot-starter-validation), so now all annotation will take effect, maybe a check will be necessary.

This pull request is actually Draft, because it constains only back development, without front developement for administration interface, users will be able to manage project access only by api call which will be very inconvenient.

Karate test hasn't been updated, they currently failed because of security change

PR CheckList

Please make sure your PullRequest respect all those items :

[x] Your PR's title has the prefix : feat:, fix: or chore:
[ ] You have asked a review from one of the ARA maintainer in your PR.
[ ] If your PR is related to an issue, add the issue's number in it.
[ ] All the code you added is documented.
[ ] All the code you added is tested and the tests are in success.
[x] You already signed the Contributor License Agreement and give us the document