[Clockwork-developers] Security

[Joel L. <jo...@lo...>]

Security is a big area to tackle in the scheduler, and it's important that it
be designed in correctly from the start. I see security used in two different
ways:
 (1) Making sure the scheduler processes on different systems communicating
     with each other are genuine and haven't been replaced with something
     that acts like the scheduler but really isn't.
 (2) Making sure that users running commands on the scheduling servers and
     through the GUI are who they say they are, so we can enforce restrictions.

I haven't devoted much thought to area #1, but I think the tougher part will
be area #2.

For the moment, let's assume that permissions restrictions are already set up,
meaning that there are rules in the scheduler saying things like "user
jlouder can do this." What I'm attempting to address is how we determine who
the user is -- without requiring the scheduler administrator to set up a
Clockwork-only user/password database.

For GUI users, we prompt them for a username and password. On the server
side, we let the administrator configure what we'll do to check usernames
and passwords. We could provide a couple of backends -- for example, one that
takes the username and password and feeds it to PAM (using a service name
of "clockwork"), and perhaps also one that feeds the username/password to
an external program, which the administrator could use to check the password
against just about anything (LDAP, NT domain, homegrown database, etc.).

For command-line users, we don't prompt for a password, but simply take the
identity of the user who's running the program. For example, if user 'jlouder'
is running the process, then we'll do all authorization checks with the
username 'jlouder'.

Of course, for a command-line program to do much of anything (say, put a
start-job event in the queue), it probably will need to talk to a scheduler
daemon running with elevated privileges. So there will need to be a check of
security credentials in that conversation. This might prevent us from not
asking local users for passwords, since we'll have to supply something to the
daemon to get checked. It's not safe to have the client tell the daemon
"I'm user XYZ, just trust me!" So obviously I need to do some more thinking
on this.

But my main goal is to *not* have to house a username/password database. I
hate applications that do that.

If you have any thoughts or comments on security, I'd love to hear them. As
you can see, I have about 20% of an idea here.

-- 
Joel