[29221] in Kerberos
Re: Kerberized authorization service
daemon@ATHENA.MIT.EDU (John Hascall)
Mon Feb 11 11:13:05 2008
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
In-reply-to: Your message of Mon, 11 Feb 2008 09:48:17 -0500.
<200802111448.m1BEmHQU006473@ginger.cmf.nrl.navy.mil>
Date: Mon, 11 Feb 2008 10:09:56 CST
Message-ID: <9279.1202746196@malison.ait.iastate.edu>
From: John Hascall <john@iastate.edu>
Cc: kerberos@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
> Let's take two real world counter-examples: the AFS PTS server, and
> John Hascall's double-secret authz server (Stanford's wallet might
> be another example, but I don't know enough about it to say so
> let's not bring that into the mix right now).
> Both services work in roughly the same way: you send them an identity
> which you have derived from your authentication service (Kerberos in
> both cases) and the service responds with what you are allowed to
> do. In the AFS PTS server's case you get a set of groups that the
> identity belongs to which are used by the AFS fileserver to determine
> permissions based on ACLs stored on directories. In the Hascall
> double-secret authz server you get a "yes/no" answer regarding access
> to a particular service (John, if I've got this wrong, please correct me).
That's correct.
To accessd: ticket, op, principal, object, mode, where-comment, by-comment
Sent back: yes/no/error
The ticket is who is making the request (e.g., the print server
or host/host.name for a login request).
Op is access (or deaccess(logout), or add/delete/rename/etc)
mode says how object is to be accessed (we use it for "su" for example)
The last two are just for accessd's log, which might be
semi-instructive:
<date> I,print.print-2@IASTATE.EDU authenticated (v4) on connection 6.
\__princ of ticket \__ugh
<date> a,john,du245-lj4.printer,,malison.its.iastate.edu,Print,ok
| | | / | | |
op | object mode where-comment by-comment answer
principal (might be telnet, ssh, su,
ftp, a cgi-program, etc)
I think this has all the elements Jeff thought were essential
except for:
1) a text reason for no <-- not seeing what you would say -- "no means no"?
2) optional group info <-- we've never seen the need, but one could
certainly add a send-me-groups opcode as it
knows that info
John
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
