[Feature] Use only NameID assertion to authenticate

[mind84]

Hi!

We encountered a situation where an IP (Identity provider) does not provide SAML Attributes as part of response, and unfortunately we cannot set those attributes in any way.

As far as we know, attributes are not a mandatory part for the SAML response protocol but, at the moment, jelix saml-module requires such attributes as mandatory for user creation/authentication on the jelix user DB.

So, given the following assumptions:

• attributes are not mandatory
• administrator user is aware of what he/she/it is doing

we would propose this PR which allow to authenticate / create the jelix user using only the NameID

Practical changes:

• a new checkbox is available in the attributes configuration page (default off)
  

-if checked, the SAML attribute containing the id/login of the user field and all mandatory attributes will be disabled and filled with an arbitrary placeholder 'NameID'

This interface management, although not very practical at the moment, serves to highlight to the user that the option is enabled.

As a result, when a user logs in for the first time, all required fields in the attributes section (marked as required by the jelix db provider) are filled with the NameID value. Obviously the value of the ǸameID could be formatted in various ways, so for example if NameID is of type username and email is a required field, the email field will be filled with a string that is not formatted as email.

We are well aware that this type of configuration is situational, but it could make the module more flexible partly by placing responsibility on the system administrator.

Thank you!

@u-cav

[laurentj]

Hi,

Sorry for the delay. And thank you for this PR.

Quick review:

1. the PR should be against the master branch, not 2.0.x
2. in the attributemapping.form.xml, you may use a <choice> element for example. One of the item could then contain the login control and attrsgroup control. The UI will be better, and no need for extra javascript.
3. Setting bad values in required fields of the user record may occurs issues in the application (for example in the email field). We may check if the format of the nameid is an email, to set the email field (but we must know which is the email field.. :-/ probably we may have a configuration property to indicate it). However, if format is not email, this is a problem.

I don't know yet how to resolve it.

I will review details of your PR and think about solutions.

(I can improve your PR if you don't have time to do it)

[mind84]

Hi @laurentj,
first of all, I'd like to apologize for the delay in responding.

the PR should be against the master branch, not 2.0.x

Okay, that's good to know for future PRs. I see you've already updated the repo, though, so thanks.

in the attributemapping.form.xml

Ok

Setting bad values in required fields of the user record may occurs issues in the application

The key point of this PR is on the provider's side. If the provider provides only one piece of information, and it's not the email address, there are two possible scenarios: use that information (and leave the administrator responsible for managing the installation) or block access entirely.
In Lizmap, as far as we can tell, the email is compulsory because it's needed for the registration email, and for password resets. Both of these are not required/triggered in a SAML configuration.

Regarding the mandatory email field, although there is no universally valid solution, we can suggest some actions that the system administrator can take to overcome this problem:

1. we can add a "domain" field next to the new admin option

   

   where the system administrator can enter the domain to be concatenated with the NameID received from the provider. For example, the system administrator could enter "@3liz.com" and every time a user is created, the system will fill in the email field with the NameID + @3liz.com. In this case, the email address entered is valid. Of course, the downside is that the user's email address must belong to the same domain (which is usually the case).

2. move the user database to PGSql or a database that supports triggers that perform the same action as the previous point, without adding a specific interface input

3. Users can still manually change their email once they log in, or the system administrator can do it.

(I can improve your PR if you don't have time to do it)

Feel absolutely free to make changes to this PR

We are of course open to discuss other solutions

Thank you!