Downloaded 25 times
Uploaded byAndrea Patricelli
Apache Syncope 2.0 Enduser UI
The document discusses the evolution and features of the Apache Syncope Identity Management (IDM) 2.0 End User UI, highlighting improvements made from version 1.0 to 2.0 and the need for a dedicated self-management tool. It emphasizes the architecture, including the AngularJS frontend, security innovations, and testing methodologies, while also outlining the functionalities required for effective user self-management. Future perspectives include enhancements like social registration and the integration of various technologies.
Apache Syncope 2.0 Enduser UI
- 1. Apache Syncope IdM2.0 Enduser UI Andrea Patricelli, Software Engineer, Tirasa s.r.l
- 2. Apache Syncope committer since2013 → PMC member in October 2016 ➔ Apache Syncope dev since 1.1.X release ➔ Apache Syncope Enduser UI ➔ Syncope Docker https://github.com/andrea-patricelli/syncope-docker About me
- 3. Agenda Introduction to theIdM world Who is the end user and why a console Enduser UI: from 1.0 to 2.0 How we made it Innovations brought Future perspectives
- 4. What's IdM about? ●Data records that contains a collection of data about a person ● “Data record” → Account ● “A person” → Identity ● The joint effort of business
- 5. ● Identity Stores ○Storage of user information ● Provisioning ○ Synchronize account data across identity stores and a broad range of data formats, models, meanings and purposes ● Access Management ○ Security mechanisms that take place when a user is accessing a specific system or functionality IdM technologies
- 6. IdM in practice:before...
- 7. IdM in practice:...after!
- 8. Apache Syncope ● Inceptionby Tirasa in 2010 ● Entered ASF incubator in February 2012 ● Graduated as TLP in November 2012 ● Active community ○ 18 committers, 6 contributors ○ ~200 mailing list subscribers, stable traffic ○ 37 releases
- 9. Who is theend user “Users whose identities are stored into Apache Syncope IdM, but that are not directly involved into other identities (administration) management flow. They interact with Apache Syncope IDM only to manage their own profile. The set of the operations provided to end users can be addressed as self- management.”
- 10. ➔ Intuitive andEasy-to-use admin console developed with Apache Wicket. ➔ Complete frontend interface of all Apache Syncope features. ➔ Role-based access to the console features: user can access to console sections only if provided with determined entitlements associated to admin specified roles. Once upon a time the Console 1.X...
- 11. And “simple” endusers?
- 12. Console 1.X forself-management Introduced since Apache Syncope 1.0.0 Self-management as integrating part of the Console. Enabled/Disabled through Apache Syncope properties, accessible from the same Console. ★ Self-registration ★ Self-update ★ Password reset
- 13. Once upon atime the Enduser UI 1.X
- 14.
- 15. The need fora more dedicated tool was raising ➔ Need to have an application completely separated from the Console. ➔ Self-management operations must be unrelated to the Core. ➔ Enduser UI should be an highly customizable component, though you can use it as- is. ➔ You can provide it with Syncope or not (i.e enable or disable self-management features). ➔ Enduser UI should also provide a certain level of configurability (we will clarify later...) Yes but...
- 16. A client-side applicationvery near to the end-user would bring (generally speaking) some not negligible advantages: ★ Parsed by the user’s browser. ★ Reacts to user input. ★ Can be seen and edited by the user in full. ★ Cannot store anything that lasts beyond a page refresh (except cookies). ★ Cannot read files off of a server directly, must communicate via HTTP requests. Why not a client-side JS application?
- 17. It would haveguaranteed all requirements needed High customizability Decoupling of the self-management features from the Console and the Core. Modularization of self-management features Better fit to customers needs about frontend console appearance From Apache Syncope architectural POV
- 18. Enduser console 2.0:how we thought it...
- 19.
- 20.
- 21. Development challenges It wasnot sunshine and rainbows… Integration AngularJS → Apache Wicket little explored E2E testing integration with Maven lifecycle EndUser UI and Admin console: sometimes similar requirements but distinct implementations because of different technologies
- 22. Main functional requirements... ➔Login page simple and linear like admin Console one ➔ Wizard-like form ➔ Form validation with custom messages ➔ Session and authentication management ➔ Integration Tests suite, integrated into Maven lifecycle ➔ User Self create/update
- 23. …and not functional ➔Highly customizable interface ➔ Easy to use ➔ Enduser console should be a “proposal”, from which the customer can start to develop his own UI ➔ Should implement all the functionalities required to self- management → not incomplete. ➔ Follow admin console evolution and replicate some core
- 24. Enduser UI innovations:Usage ★ Interactive and intelligent breadcrumb ★ Configurable wizard panels, possibility to add/remove them ★ Configurable validation ★ Configurable Password strength validator ★ Easy to configure i18n “playgound zone” at syncope-vm.apache.org:9080/syncope-enduser
- 25. Enduser UI innovations:Security ★ Authentication delegated to Apache Syncope ★ XSRF-token validation ★ Captcha validation before submitting form ★ Possibility to integrate with Google re-Captcha ★ Possibility to enable/disable security features
- 26. Enduser UI innovations:Testing ★ IT made with ProtractorJS ★ Maven-driven build process ★ Tests executed in a real browser, simulating user interaction → ProtractorJS is and e2e testing framework for web-based application written in AngularJS
- 27.
- 28. Apache Maven torun them all!
- 29. And now, isit over?
- 30. Enduser UI willfollow Apache Syncope evolution, they are indissolubly related, but (at the same time) it will ever follow a parallel flow. ➔ Social registration (Google, Facebook, LinkedIn) ➔ Deploy on lightweight containers (Payara) VS full JS backend ➔ AngularJS 2.0 support ➔ Google re-Captcha easy enabling ➔ HTML templating → custom themes Enduser UI future perspectives
- 31.
Editor's Notes
- #16 Console is a complete and ready-to-use application
- #17 We considered all possible solutions, also the one to vary a bit from the actual Console architecture and technology.
- #20 Why Apache Wicket Well known Apache framework Very easy creation of Web Application and RESTful resources Already used in Syncope, no need of new imports or new technologies, we had the solution at home
- #21 Why AngularJS? Mvc done right: Most frameworks implement MVC by asking you to split your app into MVC components, then require you to write code to string them up together again Well documented Well known to us, we did not start from scratch. Previously experienced Data models are POJO: Data models in Angular are plain old JavaScript objects (POJO) and don’t require extraneous getter and setter functions Directives: Directives are Angular’s way of bringing additional functionality to HTML ProtractorJS: easy to use end-to-end test framework for AngularJS applications
- #24 Highly customizable interface: appearance, enable/disable functionalities, etc.
- #25 Actual catpcha implementation made with Wicket
- #28 As we can see more requirements are involved As you can understand, Protractor needs a sort of environment to be prepared and made available, including dependency resolution, on-the-fly during the Apache Syncope (Maven-driven) build process! PortractorJS runs on top of NodeJS, that needs to be installed upfront. Moreover, Protractor requires a webdriver, acting as a mediator to access browsers API; we have finally chosen the implementation provided by Selenium.
- #29 Maven installs PhantomJS, Node and Protractor (pre-integration-test): once everything has been set up, end-to-end tests are finally executed (integration-test). When application is up and running (embedded mode), e2e tests can be re-executed without need of restarting anything, speeding up the test development process. Jasmine is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests.