...
Info |
This page contains topics supporting ongoing discussion at d...@syncope.apache.org. |
Tracked as SYNCOPE-1410. Overall architecture Compared to 2.1, a major architectural refactoring is proposed, with the following objectives: ...
Drawio |
border |
true |
viewerToolbar |
true |
|
|
fitWindow |
false |
diagramName |
Apache Syncope 3.0 Architecture |
simpleViewer |
false |
width |
|
diagramWidth |
1232 |
revision |
3 |
|
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
- Keymaster shall be based on existing Open Source products as Apache Zookeper or Consul
- 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
- 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
- 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.
|