Tracked as SYNCOPE-1410.

Overall architecture

Compared to 2.1, a major architectural refactoring is proposed, with the following objectives:

1. introduce a new, flexible UI for web access (Weblogin), which will replace the existing login forms for Admin Console and Enduser UI
2. introduce a new component (APIGW), which will provide API gateway features
3. introduce a new component (Keymaster) with purpose of coordinating all the other components, centralizing common configuration required by all domains; this will allow to go beyond the current multi-tenancy approach which requires a pre-existing Master domain and the need to handle off-line each domain's configuration
4. split the existing features set into three subsets, so that any given deployment will pick only what required:
   1. idrepo - everything needed to manage identities as a repository: mainly, CRUD operations on Users, Groups and Any Objects
   2. idm - the provisioning features required to propagate, push and pull identities back and forth to External Resources
   3. am - the authentication and authorization features - mostly to build on top of existing libraries

New components

Weblogin

Flexible UI for web access

1. dynamically adapting for the configured authentication features (modules, chains, levels, ...)
2. highly customizable, either graphically and processing

APIGW

At high-level, this API gateway it's an HTTP reverse proxy exposing a set of public APIs, where the response for invocation of a public API is the result of a configurable process which involves the invocation of one or more internal APIs.

Capabilities:

• configurable mapping between public and internal APIs
• authentication / authorization enforcement
• throttling
• monitor / statistics
• lifecycle management: draft / staging / published / deprecated / ...

For reference / inspiration:

• https://docs.wso2.com/display/AM260/Key+Concepts
• https://istio.io/docs/concepts/what-is-istio/
• https://github.com/getheimdall/heimdall

Good candidate for building upon appears to be Spring Cloud Gateway

Keymaster

Shall be based on existing Open Source products as Apache Zookeper or Consul

Discussion items

1. CLI was deliberately not included in the diagram above: since its introduction in 2.0, no usage at all was reported - maintenance cost does not appear worthwhile
2. It is hard to imagine how the GUI installer can cope with such complexity; proposal is to remove it as well
3. The Eclipse plugin seems also to have no users; proposal is to remove it as well
4. Enduser UI is currently implemented as AngularJS + Wicket application - but the AngularJS code appears somehow "disconnected" from the rest, and it has always been quite troublesome to troubleshoot - proposal is to rebuild as a pure Wicket application, maximizing re-use of components already working in Admin Console
5. whilst in 2.1 all applications are built as Java EE, it could be the case to switch to a more microservice-friendly approach: if so, shall we base on
   1. Spring Boot
      1. PRO
         1. easy to migrate (being the current code Spring-based)
         2. widely adopted (status quo)
         3. can be easily converted to WAR, allowing traditional deployment in existing environments
      2. CONS
         1. not real microservice, mostly an embedded Tomcat
   2. Eclipse Microprofile
      1. PRO
         1. promising approach, lot of rumors and buzz around
         2. microservice native
      2. CONS
         1. major rewrite needed in case Spring and / or CXF cannot be re-used
         2. different implementations available, not as stable and widespread as their Java EE counterparts
6. In previous Syncope versions, an admin can specify an account lockout policy that locks a user out after a number of bad login attempts. The problem is that a malicious user who knows others usernames for an account could lock users out. We should look into adding an account policy option to instead display a captcha after a number of bad login attempts.