The previous posts regarding Cosign and Yubikey two-factor authentication are intended to record the investigations and thought processes which have taken place to date during the course of this project. As such, they might seem rather theoretical – but they’re a record for us and, with luck, they might also be of use to other people thinking of implementing the same thing.
However: in practice, where are we with this project right now?
At present:
- We have a working test Cosign server, customized with the standard Informatics look-and-feel, which is configured to implement two-factor authentication; the two factors being Kerberos username/password, and Yubikey OTP.
- We have a working test Cosign client website configured to authenticate against the two-factor server.
- Almost all of the configuration for both server and client has been tidily included in the corresponding LCFG profiles, and almost all of the necessary s/w has been packaged to our usual standards. (In that respect, some work remains to be done: for example the building and installation of the ‘universal Cosign PAM factor adaptor’ needs to be integrated into our ‘normal’ Cosign packages.)
- Two test users (currently, we have only two test Yubikeys available) have been verifying the service, with good results. We find that the two-factor authentication (including Kerberos SPNEGO) works intuitively, and we are able successfully to configure different sections of the client website to require differing levels of authentication: some single-factor; others two-factor; etc. (all this being arranged via appropriate
CosignRequireFactor
entries in Apache<Directory …>
stanzas.)
In summary: the test service seems to provide what we want.
Notes:
- The configuration for the Yubico PAM module is exactly the same as described in the previous post Towards two-factor Yubikey authentication with OpenSSH, namely:
auth required /lib64/security/pam_yubico.so id=<secret> key=<secret> authfile=/etc/yubikey_mappings debug
- There is no specific ‘per-user’ treatment in the PAM configuration (as there is, for example, in the corresponding test ssh configuration described in the previous post mentioned above): anybody attempting to authenticate via a Yubikey is doing so because they want access to web content explicitly mediated via Yubikey authentication: such authentication either succeeds, or it doesn’t.
What we plan to do next:
- The current test client website is purely a proof of concept. We now plan to set up a test website to provide access to the School database (via ‘Theon’), in order to demonstrate two-factor access to ‘real’ data.
- We are purchasing more Yubikeys so that all members of the Computing staff – as well as any other interested parties – can participate in the trial.
- Currently, we associate Yubikey ID’s with School usernames via a map file – namely
/etc/yubikey_mappings
. That works, but isn’t particularly scaleable. We would like to investigate the use of LDAP to hold those mappings: the Yubico PAM modules supports that. - Currently, we use the Yubico ‘Cloud’ service as the back-end authenticator. For any real service we will need to perform Yubikey authentication in-house – so that needs investigation. Failover and/or replication of any such service needs thought.
- Some further work is necessary to tweak the HTML and Javascript supporting the two-factor Cosign service.
- Amendments to building and packaging are necessary to incorporate the Universal PAM factor adaptor into LCFG.
- And other issues will undoubtedly arise in the course of the further testing to come …