Adaptive authentication

Another interesting aspect can be considered: WSO2 IS supports adaptive au-thentication. That is, the SSO server may decide which authentication factors to require from users during sign-in based on a set of policies. For example, if users sign-in at an unusual time of the day, the SSO server may require a second factor of authentication.

Support for adaptive authentication is very limited in Keycloak 6.0.0 since custom rules be implemented only by writing a custom plugin¹⁶ or by enabling a preview feature that is not ready for production, yet.

WSO2 IS also supports step-up authentication, which is a form of adaptive au-thentication: that is, users may sign-in with their username and password only and then, when they access for example the administration panel of a SSO-enabled application, the application may instruct the SSO server to ask for a second factor of authentication. This functionality could be useful in some of the team’s custom software case and will be considered for future implementation.

16e.g. https://qiita.com/naokiiiii/items/c5bc7ed2204507f4ad6a

Chapter 4

User management application

Another component is still needed: a user management application.

The SSO server doesn’t have access to all the attributes stored in the LDAP server that other applications may need, so its integrated user management tools aren’t sufficient for this task.

It would still be possible to assign these permissions to the SSO server, but since the chosen SSO server may be changed in the future, the effort of building a simple user management panel tailored to the use case requirements may pay off, allowing to choose any other SSO server without considering the quality and features of its user management panel which is not going to be used. Moreover, this is going to make that potential migration more transparent to users and HR managers, which will see a different login page but still the same management panel.

Additionally, the registration process has some specific requirements that go beyond a simple registration form, and these are:

• Accounts should be created as locked, with the nsAccountLock LDAP at-tribute set to true, to prevent logins until the account is activated by an HR manager

• Account creation should be possible only through an invite link which is per-sonal, only one account can be created through the same invite link

• Some form fields should be pre-populated with data that is already available from the team recruitment process, for new member’s convenience

Given these requirements, which will rarely be satisfied in their entirety by a user management component in a SSO software or any standalone user management software, a decision was made to create a new software to handle registrations.

4 – User management application

The user management part was also deemed useful enough to be done, since it would require limited effort if built in the same application that handles registrations.

However, there are also more requirements for the user management part:

• Users should be able to see all their personal information and possibly down-load it for GDPR compliance

• Users should be allowed to edit only some of their personal information

• Users in a special group (HR managers) should be given permission to lock and unlock accounts and edit some personal information

• HR managers should be able to reset other users’ passwords

• Users should be able to change their own password

• HR managers should be able to download the filled SIR form for a user. This could be done through another application that leverages the Pasta software, but integrating it in the user management software will make the onboarding process even simpler

The software, named “Crauto” after a poll among team managers, has been pub-lished in a public git repository.¹ A description of the architecture and features the software follows.

4.1 Programming language and frameworks

Making such a software was also a chance to try to integrate a custom software component with the SSO server and LDAP server. Most of the team’s custom software is written in Python or PHP: using one of these languages could help in testing and better understanding what will need to be done in the future to also integrate these applications.

The existing Python software will need to be integrated with LDAP only (Telegram bot, weeelab) or leverage the SSO protocols as a way to authenticate for API access to one of the PHP applications (Tarallo). Instead, one of the PHP applications (Tarallo) will need to authenticate users with the SSO server in a manner similar to what Crauto should do, but it has no need to access the LDAP server.

For this reason a decision was made to use PHP: connecting Tarallo to SSO had a higher priority than the other software that has been mentioned, since it would simplify user management compared to the the “as is” situation and testing out PHP

1https://github.com/WEEE-Open/crauto/

4 – User management application

libraries for SAML2 or OpenID Connect would be a relevant step in the direction of integrating Tarallo with the SSO process.

Additionally, since Nextcloud had already been connected with SAML2, a decision was made to use OpenID Connect, to test the configuration of that protocol both from SSO and from an application side.

Moreover, since Tarallo is built without a framework but a set of different libraries, another decision was made to use no framework for this project, to exclude any OpenID Connect library that depends on a specific framework.

For this reason, a deliberate attempt as been made at keeping the project as simple as possible.