[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Colm O hEigeartaigh edited this page Here's what changed: ... 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. Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco edited this page Here's what changed: ... 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 IDE plugins (both Eclipse and Netbeans) seem also to have no users; proposal is to remove both 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 Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco edited this page Here's what changed: ... Info This page contains topics supporting ongoing discussion at d...@syncope.apache.org. Tracked as SYNCOPE-1410. Compared to 2.1, a major architectural refactoring is proposed, with the following objectives: ... Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new comment on this page [DISCUSS] Apache Syncope 3.0 Architecture Maxim Thomas In Spring Boot standalone app, it is possible to use Undertow instead of Tomcat, seems it shows better performance. Francesco Chicchiricco Thanks for the tip! Reply • Like View comment Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new comment on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco I have spent some time experimenting with Microprofile (as I have already quite some experience with Spring Boot), and built an Hello World application with Apache TomEE, Thorntail (former Wildfly Swarm) and Payara Micro. After doing some code and reading few blog posts, my opinion is that we should better go with Spring Boot, for the following reasons: migration of existing code will be easier (Spring → Spring, rather than Spring → CDI) Spring Boot can generate fat JARs (for standalone deployment) and plain WARs (for traditional deployment), I haven't found any way to do the same with Microprofile; this is important because we need to preserve the possibility to deploy Apache Syncope 3.0 either as a Java EE application and a microservice while at the moment we keep using Apache CXF and Apache OpenJPA even when deploying to Wildfly or Payara Micro, doing the same is not possible with their Microprofile counterparts, as the code will abstract from the concrete implementations Maxim Thomas In Spring Boot standalone app, it is possible to use Undertow instead of Tomcat, seems it shows better performance. Reply • Like View comment Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco edited this page Here's what changed: ... introduce a new, flexible UI for web access (Weblogin), which will replace the existing login forms for Admin Console and Enduser UI adapt to the configured Access Management features, i.e. if a given deployment supports a certain SAML 2.0 IdP or OpenID Connect Provider, then the login form will adapt accordingly if a given deployment requires MFA, the login form will handle the flow - see there introduce a new component (APIGW), which will provide API gateway featuresfeatures - see there 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 ... Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco edited this page Here's what changed: ... 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 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 Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new comment on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco A good candidate for APIGW could be built on top of Spring Cloud Gateway. For Keymaster, Apache Zookeper could be managed via Spring Cloud Zookeeper. Reply • Like View comment Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new comment on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco I have spent some time experimenting with Microprofile (as I have already quite some experience with Spring Boot), and built an Hello World application with Apache TomEE, Thorntail (former Wildfly Swarm) and Payara Micro. After doing some code and reading few blog posts, my opinion is that we should better go with Spring Boot, for the following reasons: migration of existing code will be easier (Spring → Spring, rather than Spring → CDI) Spring Boot can generate fat JARs (for standalone deployment) and plain WARs (for traditional deployment), I haven't found any way to do the same with Microprofile; this is important because we need to preserve the possibility to deploy Apache Syncope 3.0 either as a Java EE application and a microservice while at the moment we keep using Apache CXF and Apache OpenJPA even when deploying to Wildfly or Payara Micro, doing the same is not possible with their Microprofile counterparts, as the code will abstract from the concrete implementations Reply • Like View comment Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco edited this page Here's what changed: Info This page contains topics supporting ongoing discussion at d...@syncope.apache.org. Compared to 2.1, a major architectural refactoring is proposed, with the following objectives: ... Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco edited this page Here's what changed: ... introduce a new, flexible UI for web access (Weblogin), which will replace the existing login forms for Admin Console and Enduser UI adapt to the configured Access Management features, i.e. if a given deployment supports a certain SAML 2.0 IdP or OpenID Connect Provider, then the login form will adapt accordingly if a given deployment requires MFA, the login form will handle the flow introduce a new component (APIGW), 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 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 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 Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco edited this page Here's what changed: ... introduce a new, flexible UI for web access (Weblogin), which will replace the existing login forms for Admin Console and Enduser UI adapt to the configured Access Management features, i.e. if a given deployment supports a certain SAML 2.0 IdP or OpenID Connect Provider, then the login form will adapt accordingly if a given deployment requires MFA, the login form will handle the flow introduce a new component (APIGW), 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 Drawio border true viewerToolbar true fitWindow false diagramName Apache Syncope 3.0 Architecture simpleViewer false width diagramWidth 10031232 revision 23 Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[CONF] Apache Syncope > [DISCUSS] Apache Syncope 3.0 Architecture
Title: Message Title There's 1 new edit on this page [DISCUSS] Apache Syncope 3.0 Architecture Francesco Chicchiricco edited this page Here's what changed: Compared to 2.1, a major architectural refactoring is proposed, with the following objectives: introduce a new, flexible UI for web access (Weblogin), which will replace the existing login forms for Admin Console and Enduser UI adapt to the configured Access Management features, i.e. if a given deployment supports a certain SAML 2.0 IdP or OpenID Connect Provider, then the login form will adapt accordingly if a given deployment requires MFA, the login form will handle the flow 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 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 Drawio border true viewerToolbar true fitWindow false diagramName Apache Syncope 3.0 Architecture simpleViewer false width diagramWidth 1003 revision 12 Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
