Add basic Kerberos authentication

[jjaraalm]

In on-premises deployments, user accounts are often centrally managed. This PR adds basic authentication against a trusted Kerberos or Active Directory setup.

Usernames are passwords are validated against the KDC, but the integrity of the KDC itself is not validated. This would require registering HSDS with the KDC and distributing private keys to all containers. Doable, but more complex and site-specific setup.

This does not implement Kerberos-based single-sign on (HTTP Negotiate) which also requires registering HSDS with the KDC, but the gssapi package can be used to implement this in the future.

[jreadey]

@jjaraalm - could you merge in recent changes from master? Thanks.

[jjaraalm]

Sure, I'll do that in a bit. I think your changes with PASSWORD_FILE conflict with some things I did, so I'll need to revert.

In general, how do you feel about this? Is it too site-specific or does it make sense with the overall plan for HSDS?

[jreadey]

Is this still HTTP Basic auth - just using Kerberos to validate the username/passwords?
I've recently added support for token based authentication using Azure Active Directory - see _verifyBearerToken in authUtil.py. This required some changes in h5pyd to create the proper Authorization header.

Kerberos support doesn't seem that site specific - I assume this is used by a lot of organizations.

You noticed in a recent checkin that the password file is no longer built into the docker image. This seems better in that the images can be shared (e.g. on Docker hub) without passing everyones passwords around. Now the password file is either mounted (for Docker) or compiled as a secret (for Kubernetes) For similar reasons, I'd suggest not build the krb5.conf file into the image.

Can the krb5.conf values just be passed as environment variables as with the other config settings?

Passing all the config values as environment variables does get a bit tedious. I've been thinking it might be better to do the same mount/secret thing for the config.py JSON data and do away with the environment variable method.

[jjaraalm]

Still basic auth using kinit-like flow to authenticate.

Under the hood, the username is sent to the KDC configured in krb5.conf. The KDC responds with a message that is encrypted using the hash of the password on the KDC. If this can be decrypted using the password given in the basic auth header, then gssapi and hsds successfully authenticate the user.

If you have framework in place that could be used for oauth (specifically Google oath), then I would actually prefer that over using Kerberos for our site.

[jreadey]

I suspect the same code in _verifyBearerToken could be modified to work with Google oauth if you want to go that way.

[jjaraalm]

I took at look into oauth, and implementing Google oauth seems pretty simple on the server side. Clientside, it looks like Azure-specific stuff is hard-coded into h5pyd. For now, I'm going to abandon this branch and try and put together PRs for Google oauth on client and server side.

[jreadey]

@jjaraalm: Do we want to keep this open or is it superseded by #52?

[jjaraalm]

Personally, I think the overhead of Kerberos is kind of a pain. I think we can close this unless anyone really wants this feature.