Apache Syncope IdM 2.0 Enduser UI

Andrea Patricelli, Software Engineer, Tirasa s.r.l

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

Agenda

Introduction to the IdM worldWho is the end user and why a consoleEnduser UI: from 1.0 to 2.0How we made itInnovations broughtFuture perspectives

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

● 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

IdM in practice: before...

IdM in practice: ...after!

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

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.”

➔ Intuitive and Easy-to-use admin console developedwith 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.

➔ Born mainly to manage identities from an admin POV.

Once upon a time the Console 1.X...

And “simple” end users?

Console 1.X for self-managementIntroduced 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

Once upon a time the Enduser UI 1.X

Isn’t this enough?

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...

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?

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

Enduser console 2.0: how we thought it...

...how we made it

AngularJS Frontend

Development challenges

It was not sunshine and rainbows…

Integration AngularJS → Apache Wicket little exploredE2E testing integration with Maven lifecycleEndUser UI and Admin console: sometimes similar

requirements but distinct implementations because of different technologies

Client-side JS application security issues.

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➔ User Self password reset

…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

functionalities➔ Provide client-side application security features

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

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

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

ProtractorJS workflow

Apache Maven to run them all!

And now, is it over?

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

Join the discussion! https://s.apache.org/syncopeEnduserDiscuss

Enduser UI future perspectives

Questions?