[Technical] Upgrade Services to Spring

[boubaker]

Rationale

After Spring Integration MIP #57, the Service layer isn't completely which makes the usage isn't exclusively made by new technologies in new development. We will need the act the effective upgrade to Spring in Service layer in order to enforce the new development Best practice.

1. Functional Requirements

No functional changes has to be made.

2. Technical Requirements

Expected Volume & Performance

N/A

Security

Allow to access Spring REST using Basic authentication.

Extensibility

All Meeds REST endpoints has to be accessible using associated Web Archive of each extension.

Configurability

N/A

Upgradability

N/A

Existing Features

N/A

Feature Flags

N/A

4. Software Architecture

Security

Allow to access Spring REST using Basic authentication.

Access

All Meeds REST endpoints has to be accessible using associated Web Archive of each extension.

Services & processing

N/A

Data and persistence

N/A

[boubaker]

Ready for tech review by Meeds DAO members ( eXo: @rdenarie )

[rdenarie]

About the security part, and the Basic Authentication, is it possible to make it "activable" ?

In some context, we need this authentication, but in other, for security reason, we need to close this door, and not expose endpoint with basic auth, because for example, we use a sso context like SAML or other, and we dont want that user access to rest endpoint with 'internal' exo account.

So for me, some features are needed :

• Possibility to activate/deactivate the BASIC authent - MUST
• Possibitity to restric users who can access to this basic authentication, by listing them OR by generating and API token. - SHOULD

I speak about this point because you mentionned it in the security part, BUT, we have to discuss if this concern is part of this mip or not.

[boubaker]

The idea is to keep the same features as now without changes.
We can consider enablement or restriction features in MIPs apart.

Thus to not combine multiple concerns in one, which may lead to an excessive cost to this first outcome, both suggestions can be considered apart (same as API tokens which I suggested multiple times before, but not prioritized yet. Besides we will need this for Gamification Module interoperability)

[rdenarie]

Ok, no problem.

I came to this reflexion when viewing the security part, and after writing requirements, I remark that it was not the center of the MIP, so no pb to consider it in another MIP.
Ok for me

[boubaker]

Thanks for the feedback, Go-func added as well since no functional changes required on this.

[boubaker]

Merged to develop for kudos & app-center