delegating principal creation to a web process

[Simon Wilkinson]

On 20 Mar 2008, at 17:52, Jason Edgecombe wrote:

> We're working on creating a process that will automatically create a
> kerberos principal for a user when they agree to the computer policies
> on a web page.

We do this, although probably in a less restricted fashion than you  
desire.

Our 'Friend' scheme for electronic visitor accounts uses a KDC to  
store the passwords for these accounts (this has the advantage that  
both 'friend' and 'normal' accounts are backended by the same  
authentication technology - and lets us use credential delegation in  
services designed for both classes of users). You can have a look at  
the public facing portions of it at https://ifriend.inf.ed.ac.uk/

> I'm looking on advice on how to best to write a system that will be  
> run
> by the web server and create the specified user account on demand and
> set the password. I plan to use a custom kerberos principal for this
> purpose with the right to create principals on the KDC. The only thing
> that is passwd in is the username and password. I was planning on
> storing this custom principals keytab in a local file. Besides having
> files readable only by root and only allowing the web server user  
> to run
> the program and verifying my input. how can I keep this relatively
> secure?

remctl is your friend for this kind of priviledge delegation task.  
You can use it to front kadmin, and it will give you far more  
powerful ACL and data validation rules than kadmin supports.

> This is a shared web server that serves php from our students
> home pages, but no one besides staff members has shell access.

The main thing you have to consider is how to restrict access to the  
creation script such that it can only be run by the webserver (and  
not by any of your students PHP scripts). You also have to make sure  
that the script can only be invoked from the correct start page -  
CSRF attacks are incredibly insidious, and very damaging to this sort  
of application. It's not clear from your description how you check  
that the script is creating the 'correct' account name for a  
particular user - nor how you protect against denial of service  
attacks, or attacks which create 'magic' account names (root, <blah>/ 
admin, anything else your site has in a wildcard)

Hope that helps,

Simon.