This page contains topics supporting ongoing discussion at dev@syncope.apache.org.
Tracked as SYNCOPE-1410.
Overall architecture
Compared to 2.1, a major architectural refactoring is proposed, with the following objectives:
- introduce a new, flexible UI for web access (Weblogin in the picture, renamed as WA), which will replace the existing login forms for Admin Console and Enduser UI
- introduce a new component (APIGW in the picture, renamed as SRA), which will provide API gateway features
- 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
- split the existing features set into three subsets, so that any given deployment will pick only what required:
- idrepo - everything needed to manage identities as a repository: mainly, CRUD operations on Users, Groups and Any Objects
- idm - the provisioning features required to propagate, push and pull identities back and forth to External Resources
- am - the authentication and authorization features - mostly to build on top of existing libraries
New components
WA (Web Access)
Flexible UI for web access
- dynamically adapting for the configured authentication features (modules, chains, levels, ...)
- highly customizable, either graphically and processing
SRA (Secure Remote Access)
Tracked as SYNCOPE-1455.
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
Tracked as SYNCOPE-1456.
This component serves three purposes:
- allow for Service Discovery (Core needs to call SRA, Console needs to call Core and SRA, SRA needs to call Core, and so on)
- act as shared repository for Configuration Parameters
- allow for dynamic Domain management, eliminating the need to restart / redeploy to onboard new Domains.
It is needed to provide two distinct implementations of Keymaster:
- one - backed by an existing Open Source product as Apache Zookeper or Consul - to cover microservice deployment scenarios
- one "embedded" to keep covering ordinary, non-microservice deployment scenarios
Discussion items
- 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
- It is hard to imagine how the GUI installer can cope with such complexity; proposal is to remove it as well
- The Eclipse plugin seems also to have no users; proposal is to remove it as well
- 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
- 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
- Spring Boot
- PRO
- easy to migrate (being the current code Spring-based)
- widely adopted (status quo)
- can be easily converted to WAR, allowing traditional deployment in existing environments
- CONS
- not real microservice, mostly an embedded Tomcat
- PRO
- Eclipse Microprofile
- PRO
- promising approach, lot of rumors and buzz around
- microservice native
- CONS
- major rewrite needed in case Spring and / or CXF cannot be re-used
- different implementations available, not as stable and widespread as their Java EE counterparts
- PRO
- Spring Boot
- 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.