Options for authentication

[JimMadge]

What we want

• centralised authentication
• MFA
• Users declare their own password and setup MFA (admin does not see credentials at any point)

Options

• OpenLDAP + KeyCloak frontend (We could ask the Baskerville team at Birmingham about this)
• FreeIPA - AD style system with LDAP, DNS, NTP and a web portal for admins

[jemrobinson]

LDAP

• OpenLDAP as an LDAP server in the SHM with pre-defined users

Self-service password reset

• Authelia exposed at a public URL
  • requires an SMTP server as the password reset goes over email (could this be a Turing SMTP server? If not, how about a free SMTP service?)
• Self-service password exposed at a public URL
  • can use an SMTP server
  • or an SMS server (need to pay for a provider)
  • or security questions (no external integrations needed)
• FreeIPA Password Reset

MFA

• Authelia with native TOTP plugging in to Guacamole as an OpenID connect provider
  • this would run in the SHM giving one TOTP code per account
• Guacamole with native TOTP stored in the local user database
  • this would run in the SRE giving one TOTP code per project (multiple accounts with the same email address might not work in some TOTP apps)

Other options

Another interesting option would be to use ORCID as an OpenID connect provider. With an institutional account you can find out whether 2FA was used (but I'm not sure whether Guacamole would be able to reject non-2FA logins). Note that this option would still need a local LDAP database.

Personal preference

• SHM OpenLDAP (for holding users)
• SHM Authelia (exposed as https://auth.<shm domain> for self-service password reset and TOTP registration)
• SRE Guacamole using Authelia via OpenID connect for MFA-enabled login and pg-ldap-sync to a local database to match OpenID details against OpenLDAP

[JimMadge]

requires an SMTP server as the password reset goes over email

My feeling is requiring an SMTP server isn't unreasonable considering who we expect to be running a safe haven. I have good experience with migadu where you can bring your own domain.

Do we have strong feelings about whether MFA should be one per identity or one per project per identity?

About your preference,

Is Authelia only there to enable self-service password reset (given Guacamole can force initial password reset and enforce TOTP)? Should not letting admins be able to see initial credentials be the hill we die on? Don't we already give admins a massive level of trust already? The real risk here was intercepting credentials.

Is pg-ldap-sync there to recreate entries from the LDAP server in Guacamoles local database? Can we not just configure Guacamole to use the LDAP server? Not in combination with OpenIDConnect. This is a way to replicate the machine allocations on LDAP to the Guacamole database. An alternative would be to manage the connections just in Guacamole.

[jemrobinson]

Note, a future standalone SRE (with no SHM) might need the following:

• DNS server
• NTP server
• Repository mirrors/proxies
• LDAP server
• Password reset (eg. Authelia)
• Guacamole server
• Compute
  • SRD (one or more)
• Webapps
  • CodiMD
  • CoCalc
  • GitLab
• Databases
  • SQL server
  • postgresql

[JimMadge]

That list sounds right. We might be able to drop a few things (CoCalc, do we need two SQL databases?).

If we choose to go that route, FreeIPA would naturally consilidate LDAP, DNS, NTP into one host.

[jemrobinson]

Note that if we're unhappy with running our own MFA, we could use Guacamole's Duo integration. Note that Duo lets you sync users from your local LDAP server. Also, it's free for <10 users.

[JimMadge]

@jemrobinson A note about FreeIPA and containerisation which I tried (poorly) to explain before.

FreeIPA isn't an application with a single entry point. It is better to think of it as a collection of related services running on a single machine. Because of this "The FreeIPA container runs systemd to manage all the necessary services within a single container.". This requires adding capabilities and/or mounting systemd files from the host system. I expect this would be difficult, if not impossible, on a container service.

It looks like this is still the case even with Podman and unprivileged containers

I think the take-home message is. You can run systemd (and hence FreeIPA) in a container. But you still need access to the host system.

[JimMadge]

Looking at self-service password reset

Free IPA Password Reset

• Not actively developed

LDAP Tool Box Self Service Password

• Password policy implementation
• Reset by email, sms, questions

Authelia

• Password policy is not implemented yet but is on the way Password policy is merged
• Reset by email

[JimMadge]

I think that rules out using authelia at the moment but not in the future. We can still get the second factor using the Guacamole TOTP plugin.

[JimMadge]

Proposal for a structure,

It would be good to keep in mind supporting 'bring your own LDAP' and leave this option open. It could be very helpful for organisation that already maintain their own directory.

We will build a 'reference' LDAP implementation that anyone can use for self-contained SREs. This implementation will consist of,

• OpenLDAP
• LDAP Tool Box Self Service Reset
• Command line tool for managing users (add, disable, remove) (Alternatively, a web interface like phpLDAPadmin and instructions access via SSH tunnel/VPN or way to expose LDAP to use tools like Apache Directory Studio)

Guacamole connection information will be stored in LDAP.

For LDAP authentication Guacamole requires,

• guacConfigGroup be applied
• LDAP parameters (hostname etc) be declared
• Database setup for storing TOTP data which can be linked with LDAP
• Connections defined using the Guacamole schema

Ubuntu requires,

• SSSD configuration (Section SSSD and LDAP)

LDAP Toolbox SSP requires,

• LDAP configuration
• Users have email declared and attribute confirmed for email reset

[JimMadge]

@jemrobinson @martintoreilly Here is the self-service password reset by email token flow for LDAP Toolbox SSP.

The third image shows how the password policy is presented to users.

[jemrobinson]

Looks good! It would be great if

1. the initial invitation to the self-service password reset site (with username)
2. the password reset link with token

could be sent via different channels (eg. email/SMS/Slack/something else). What options do you think we have for doing this @JimMadge?

[JimMadge]

Regarding 1. We could do that. Set an initial, random, long password and direct the users to the SSP page.

Regarding 2. It would be a little hacky, but you could send the emails to a local mail server and then 'do whatever you want' with the email contents.

As an alternative, the same project supports reset by by SMS. Here a reset code is sent by SMS instead of a link+token. The docs have a few examples for specific SMS providers as you need to include your own send_sms_by_api function.

[JimMadge]

@jemrobinson A thought about hardening guacamole,

The enrollment process used by Guacamole’s TOTP support needs to be able to store an automatically-generated key within the user’s account. Another extension must be installed which supports storage of arbitrary data from other extensions. Currently the only extensions provided with Guacamole which support this kind of storage are the database authentication extensions.

If in the future Guacamole is able to store arbitrary data in an LDAP instance, then we could do away with the database and the guacadmin user. That way it would be possible to use Guacamole TOTP while not having a privileged account that can connect to the guacamole portal.

[jemrobinson]

We don't actually create a guacadmin user at the moment and I'm not sure whether we need one. The main use of one in our case would be killing unnecessary user sessions, but I think that's not important enough to be worth the added risk.

[JimMadge]

Do we explicitly delete the guacadmin user? One is created by default, perhaps this is in the postgres init_db script?

If you had one (or any admin account in guacamole) you could use it to create connections/users/etc. using either the web interface or the API.

[jemrobinson]

Yes, it's in the init_db script, but I've removed it for the version we're using.

[JimMadge]

Password reset (user registration) options

SMS

LDAP SSP SMS works by sending a code to the users mobile number which they are challenged to enter.

The app supports triggering your SMS service by email or API.

The API option requires you to write code to interact with your SMS provider, either directly in PHP or by calling an external program. This gives a good amount of flexibility to use your providers API through HTTP or their own SDK in PHP or another language.

The Azure SMS SDK supports C#, Java, Javascript and Python SMS on Azure is only available to US phone numbers using a US toll-free number see here and here. Sending SMS is also not available for subscriptions with UK billing addresses

We could consider services which offer sending SMS using an API. For example,

• https://www.messagebird.com/en/
• https://www.smsglobal.com/

This would add an extra account and cost for those wishing to deploy a safe haven.

The upside of using SMS is that it would give us strong confidence in the identity of users. In order to set their initial password, and change their password, a person would need to control both the phone and mailbox that belongs to the individual we want to give access to. A username would be sent by email, and a password reset code by SMS.

It is conceivable that either the email or SMS could arrive at the wrong person. However, both arriving to the same wrong person is very unlikely.

Alternative to SMS

As the LDAP SSP SMS function essentially allows us to send a short message containing the reset code to a function we control, we can look at other messaging services like Signal, WhatsApp.

Signal

We can use signal-cli to send messages. This is an unofficial cli interface to the libsignal API.

A phone number is required to register. This can be a number supporting only voice.

The configuration process is manual and awkward involving completing a captcha challenge and copying a secret from an HTTP response.

After configuration settings are stored in files.

It might be possible to perform registration outside an SRE then provide the configuration files to a container with the SSP app and signal-cli.

An advantage here is that we avoid setting up an additional account and billing with an SMS provider, which would involve a similar (probably greater) level of manual intervention.

Note It may be the case that a signal account can only be registered to a single device. This might mean that each SRE would require it's own phone number. However, copying a single signal-cli configuration between machines may make each appear as a single device.

[jemrobinson]

Azure AD domain services

@martintoreilly is keen on exploring Azure AD domain services again. This requires:

• a dedicated Azure tenant (with complete control over admin accounts, so not purchased through a third-party)
• subscriptions living under that tenant that can host Azure AD domain services and the rest of the Safe Haven
• (ideally) a way to pay for the above that doesn’t need someone to pay on their own credit card

Note There can only be one AADDS for each AAD which means:

• EITHER: only one SRE per tenant
• OR: keeping the current SHM/SRE setup with at least some of the associated difficulty when upgrading and potentially the security issues of inter-SRE access via the SHM.

Note Also see this list of limitations of Azure AD domain services.

[jemrobinson]

I've been working on pam-aad-oidc to allow us to run PAM authentication directly from the SRDs to AzureAD using OpenID connect. As Guacamole can already authenticate against AzureAD with OpenID connect, this means:

• we don't need any local ID server
• we can (in future) look into how to support arbitrary OpenID endpoints