Since its birth Apache Syncope developers faced the problem (and the challenge) to have an easy-to-use, intuitive, but complete front-end application to let plain users self-registering, managing own profile, resetting their passwords and other self operations. Up to Syncope 1.2, some features used to be provided via the admin console, but the need for a more dedicated tool was raising.Therefore Apache Syncope developers, decided to deliver with Apache Syncope 2.0 an easy-to-use, client-side, highly customizable AngularJS Enduser application. In his work Andrea Patricelli will explain his personal contribution to development of Apache Syncope 2.0, innovative approaches used to develop Enduser, challenges faced while developing and future perspectives opened by this new Apache Syncope module.
2. Apache Syncope
committer since 2013
→ 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 the IdM 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
8. Apache Syncope
● Inception by 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 the end 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 and Easy-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...
12. Console 1.X for self-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
15. The need for a 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 application very 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 have guaranteed 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
21. Development challenges
It was not 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
30. Enduser UI will follow 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
Console is a complete and ready-to-use application
We considered all possible solutions, also the one to vary a bit from the actual Console architecture and technology.
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
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
Highly customizable interface: appearance, enable/disable functionalities, etc.
Actual catpcha implementation made with Wicket
As we can see more requirements are involvedAs 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.
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.