[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On expiration times and API.
From: |
Mats Erik Andersson |
Subject: |
On expiration times and API. |
Date: |
Sat, 20 Apr 2013 00:04:25 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Dear all,
let me make a proposal for extending the API,
based on three facts:
* The utility 'kinit' of Solaris', using a variant
of MIT Kerberos, is per default producing a
TGT-REQ with fields
req-body.endtime = 2037-12-31 00:00:00
req-body.rtime = 2037-12-31 00:00:00
unless overriden by '-l lifetime' and
'-r renewable_life'.
* In 'src/kdc.c', function asreq1(), the client
request is supposed to be adapted to local
policy regarding TGT expiry and renewal limit.
This is outlined in the comments, but is not
implemented in practice.
* 'src/kdc.c' has no access to "lib/internal.h",
whence 'shishid' has no possibility to read
neither 'handle.ticketlife' nor 'handle.renewlife'.
To implement the indicated expiry policy I imagine
four new API calls:
time_t shishi_endctime_realm (Shishi *handle, char *realm)
time_t shishi_renewctime_realm (Shishi *handle, char *realm)
time_t shishi_endctime_hint (Shishi *handle, Shishi_tkts_hint *hint)
time_t shishi_renewctime_hint (Shishi *handle, Shishi_tkts_hint *hint)
Better functions? Previously implemented alternatives?
The configuration items
ticket-life=TIME
renew-life=TIME
would state the default, server specific timing, while the new items
realm-ticket-life=REALM,TIME
realm-renew-life=REALM,TIME
could cover realm specific limits. A further detail requires
scrutiny: Which upper limit is suitable for absolute upper
limit for expiry time? I am inclined to use
'now' + 4 * 'default ticket life interval'
where the factor four is open for discussion.
Best regards,
Mats E A
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- On expiration times and API.,
Mats Erik Andersson <=