SSO/SAML integration & 2FA - how to disable Single Factor Authentication

Bug #1855418 reported by Lorenzo Cavassa
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Keystone Charm
Triaged
Undecided
Unassigned

Bug Description

We have configured Keystone Mellon integration so that users get authenticated by an external SAML provider which in our case provides 2FA.

https://jaas.ai/u/openstack-charmers/keystone-saml-mellon

Which is the best way of disabling single factor password authentication for these users?

Tags: atos
Revision history for this message
Alex Kavanagh (ajkavanagh) wrote :
Download full text (3.8 KiB)

I set up a Federated SSO/SAML system using SAML Test (https://samltest.id/). The most recent OpenStack version that the keystone-saml-mellon charm supports is Queens, but, I've checked more recent versions and the SAML features are essentially the same.

The main question asked is:

> Which is the best way of disabling single factor password authentication for these users?

I approached this question from the perspective of Horizon (OpenStack dashboard) and Keystone. It is also assumed that the user is a federated user without admin privileges.

Summary: Federated accounts do not have a particularly good treatment in the OpenStack dashboard; they feel more like an 'add-on', which in truth, they probably were. In particular, there isn't any code that detects that the user is federated and thus shouldn't be shown password change forms. However, as the user has no password (in keystone) they aren't actually able to change or set their password in the OpenStack dashboard. Annoyingly, it seems very tricky to not show forms that are not relevant to the federated user.

It is possible to stop users from setting or changing their passwords at the CLI/Horizon. Keystone has a lock password option for the user, but there appears to be no way to actually do it via the openstack command. It's only possible via a direct call to the keystone API: [1]

This could be achieved using a small Python script to 'lock' all of the users in a federated domain. This would disable that user from setting a password (and thus setting up a password for the user to enable logging in without using SAML). This would need to be repeated when new federated users log in for the first time, as that is when the associated keystone account is created, so it's less than ideal.

On the dashboard, unfortunately, federated accounts still get shown a password change form as part of their settings. If they have no password set (the default with a federated account) then they can't "change" or set their password. Disabling the form may be possible with a custom HTML using hz-if-policy feature [3], but might require changes to the Angular code. This would require a policy override of "identity:update_user" which could be written to disable the feature for the federated_domain. This would then require modification to the dashboard to use (say) hz-if-policy to not show the password update page; the action would also be disabled in the core code.

---

So to summarize the options:
============================

- Lock the users' passwords using a Python script. Have to be repeated frequently, and there would be a small window for users to set a password via the CLI.
- disable "identitiy:update_user" for 'normal' users, or restrict via domain id using policy override.
- Disable showing items in browser by using the HTML attr: hz-if-policy -- however, it's not clear if this is actually supported in the password fields.
- Add admin password to the Horizon change_password page [2] (thus 'disabling' a user from changing their password), using the option: ENFORCE_PASSWORD_CHECK. However, this would need adding to the openstack-dashboard charm as a feature as currently the default ch...

Read more...

Andrew McLeod (admcleod)
Changed in charm-keystone:
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.