Implement CA admin panel

[RequestForCoffee]

Closes #38.

Summary:

• Single-UID-column admins table added to the user database to be able to designate CA admins without altering the legacy schema
• Cert authentication handler attaches a custom identity claim to users present in the admins table - this is not done in the cookie auth handler since the admin panel is only available via client cert authentication
• Users with the admin claim (i.e. authenticated using a certificate and with their UID in admins) see an "Admin dashboard" link in the navbar
• Admin dashboard has a certificate-only and admin-claim-requirement authorization policies applied

Open question: the current implementation has a loophole around the client certificate auth requirement: the CA admin may authenticate using username+password as a regular user, obtain a certificate, and re-authenticate using the certificate to access the admin panel (they still have to be in admins though). If we disable username/password auth for admins, we face another problem: how can the CA admins get their certs in the first place?

[keyctl]

I'm currently building this on a new instance.

[keyctl]

Am I correct that this depends on #67?

[keyctl]

I've merged client-cert-auth on top of this and get a blank page on login. The log says the following.

MySql.Data.MySqlClient.MySqlException (0x80004005): SELECT command denied to user 'aslweb01'@'aslweb01' for table 'admins'

[keyctl]

@RequestForCoffee I've added a patch that makes this work for me. Can you confirm that it still works for you?

[RequestForCoffee]

My bad, I've tested mysql locally and just that the script itself completes. Missed the permissions - I would expect it to work now.

[RequestForCoffee]

Am I correct that this depends on #67?

To run on vagrant, yes. Locally, it's fine as-is.

[Miro-H]

Open question: the current implementation has a loophole around the client certificate auth requirement: the CA admin may authenticate using username+password as a regular user, obtain a certificate, and re-authenticate using the certificate to access the admin panel (they still have to be in admins though). If we disable username/password auth for admins, we face another problem: how can the CA admins get their certs in the first place?

Hm. We can always say that administrators must go in person to the sys admins and request a certificate ("extended validation" for humans so to say). But they should still be able to revoke their certificate. Would that be a feasible change to disable certificate issuing for admins?

[keyctl]

Hm. We can always say that administrators must go in person to the sys admins and request a certificate ("extended validation" for humans so to say). But they should still be able to revoke their certificate. Would that be a feasible change to disable certificate issuing for admins?

Then we could just say they obtain a certificate once when starting to work at iMovies, and have to retrieve a new one physically if they lost access. Then they'd at least be able to issue new certificates themselves? So we can block access via password for them...

[RequestForCoffee]

Would that be a feasible change to disable certificate issuing for admins?

The concern there is how do we provide the CA admin cert for the reviewing group? Some kind of ansible script to generate and pre-install it on the client box?

[Miro-H]

Would that be a feasible change to disable certificate issuing for admins?

The concern there is how do we provide the CA admin cert for the reviewing group? Some kind of ansible script to generate and pre-install it on the client box?

Might be possible. But if they revoke that certificate, then they cannot easily obtain a new one... Actually, we might be better off just noting in the report that this loophole exists. Because to be honest, the data that a admin sees is not so sensitive in my opinion.

[keyctl]

Because to be honest, the data that a admin sees is not so sensitive in my opinion.

I think the task of implementing any admin functionality is just a placeholder for some sensitive activity. We should learn how to deal with sensitive user accounts properly. So I think you're correct that we could go the easy-out and just mention it, but there not being sensitive information isn't a valid reason in my view.

[Liblor]

But then there is no real benefit for certificate-only authentication. I don't think we really need it anyway, or did I miss something?

[Miro-H]

But then there is no real benefit for certificate-only authentication. I don't think we really need it anyway, or did I miss something?

It's a requirement

[Liblor]

Oh, true, I forgot...

Might be possible. But if they revoke that certificate, then they cannot easily obtain a new one... Actually, we might be better off just noting in the report that this loophole exists. Because to be honest, the data that a admin sees is not so sensitive in my opinion.

I'd just write a warning in the readme. If they revoke it without generating a new one, they can install the setup again ;)

[RequestForCoffee]

So, do we keep it as-is and argue this makes it easier for the reviewing group to test it, acknowledging the loophole, or disable password login for CA admins and pre-install a single certificate using ansible?

[Liblor]

disable password login for CA admins and pre-install a single certificate using ansible

If it isn't too much of a hassle to setup, I'd go for this solution.

The reviewers have two options if they mess up:

• reinstall the VMs
• SSH to asldb01, execute an sql query to unset the admin flag locally [they have the credentials], generate a new certificate via webapp, set the admin flag again.

[Liblor]

I'll wait for a fix of my issue in #67 before I review this (in order to test it on the VMs)

[RequestForCoffee]

disable password login for CA admins and pre-install a single certificate using ansible

If it isn't too much of a hassle to setup, I'd go for this solution.

Will implement this before moving on to the backdoors today.

[RequestForCoffee]

Disabled CA admin password login; cert pre-installation happens in two stages:

Ansible:

• aslcert01 runs a python script locally to produce a CA admin cert; this is done on aslcert01 to avoid the TLS auth requirement from outside boxes
• aslans01 pulls the cert to the config server and removes it from aslcert01

Vagrant:

• Client provisioning script uses scp to pull down the pfx to the admin user's home directory
• Certificate passphrase is correct horse battery staple
• CA admin user changed to ms instead of a3 since a3 has an easier password for typical testing.

[Liblor]

hm, I didn't have the cert preinstalled... but I forgot to merge master into it. I'll retry, so it might take a while again...

[RequestForCoffee]

hm, I didn't have the cert preinstalled... but I forgot to merge master into it. I'll retry, so it might take a while again...

The cert should be present at /home/admin/*.pfx on the client machine - it's not installed into firefox to not interfere with typical user testing.

[keyctl]

The cert should be present at /home/admin/*.pfx on the client machine - it's not installed into firefox to not interfere with typical user testing.

It should generally not be a problem having the admins certificate installed for the user admin:admin, and still allowing using passwords for the user user:password on aslclient*.

[keyctl]

* Certificate passphrase is `correct horse battery staple`

We have to make this really clear in the report, because otherwise the group cannot access the admin interface.

[keyctl]

@RequestForCoffee I've added a few comments. Once resolved, this is ready to merge. I've tested this (excluding the number of certificates expired) and it works as expected.

[RequestForCoffee]

* Certificate passphrase is `correct horse battery staple`

We have to make this really clear in the report, because otherwise the group cannot access the admin interface.

Agreed!

[RequestForCoffee]

The cert should be present at /home/admin/*.pfx on the client machine - it's not installed into firefox to not interfere with typical user testing.

It should generally not be a problem having the admins certificate installed for the user admin:admin, and still allowing using passwords for the user user:password on aslclient*.

I thought firefox uses a shared (non-user-specific) cert store? If not, I guess I can look at preinstalling, assuming the screenshot hack works :)

[keyctl]

I thought firefox uses a shared (non-user-specific) cert store? If not, I guess I can look at preinstalling, assuming the screenshot hack works :)

It's definitely profile-based for public certificates, and I'd assume this is the case for private keys, too. So it could be shared, but not concurrently used. Normally, every user has their own profiles in their home directory. Don't bother with this until everything else is done, though.