Allow anonymous access to log control if desired

[at88mph]

Some systems do not have access control around the log control servlet. It would be nice to provide a way to allow anonymous access, or at least have some known token that can be used. The current library requires authentication.

[at88mph]

I had entertained proposing either an Anonymous user, which is the same as some throw away user that is only used for this purpose, or to require a token (or Request header) that the caller could provide to indicate some authorized use.

[pdowler]

so the use case is

1. a deployer has a service that can be called anonymously so they have no need for an A&A system for regular usage
2. the deployer does want to make use of logControl features

[at88mph]

Correct.

[pdowler]

One thing that has come up in various places is the desire/ability to configure users and/or groups with permission to access. In luskan we can configure only groups, while in cred we can configure only users... in most places some direct user config would be really helpful (eg if minoc could be configured to allow the storops DN to read any file, critwall file sync would work when ac and cred were down).

now, LogControl does allow user and group config (via the log control properties file), so the one thing that works right now is to configure an X509 DN and use a client cert to access /logControl. Certs are kind of a pita, so we should allow for other user identity types to be configured anyway....

If we allowed "username" then someone could put a username + password challenge in front of /srv/logControl or someone with an A&A system that uses tokens could use tokens as usual. In principle, someone could generate a key pair (cadc-keygen or ssh-keygen equiv), put the pub key(s) in the service, and use the private key to generate tokens (then use curl -H "authorization: bearer $token"). We'd have to create a command line utility to generate and sign the token, but we have all the code to do it in cadc-util... that last one is probably more work than it's worth.

We could go as simple as allowing someone to configure a "secret" and then simply pass the secret in via header or param. That would be better than allowing anon and probably better than a username + password challenge (because of reduced scope to access just this one thing).

I would say we will want to support user to be a dn, username, and we could add secret. To generate the right kind of Principal, we'd need to specify type in the config file, eg:

x509 = cn=foo_123,org=bar,c=ca
username = foo
secret = d41d8cd98f00b204e9800998ecf8427e

group = ivo://example.net/gms?devops

and keep user = {dn} as well for compat (to be removed later).

There are a couple of other places where one wants authenticated access in an otherwise anon service so if this works out it could be useful there too.

[at88mph]

This Issue would then be to add support for username and secret into the LogControlServlet to protect the POST endpoint. Is that clear? I would pass the secret as an x-cadc-logcontrol header, or I suppose since it's a POST it could be in the body as a secret=. OK to start work on that?

[pdowler]

yes, I think secret as a param is probably OK. Go for it.