> But, we are using a cookie that's a random 128 character string, and we
> have a daemon that handles mapping the cookie to a username. At this
> point we're also not storing ticket files of any sort, as I don't want
> access to the web server to automatically compromize anyone who is using
> it from a browser, and the cookies only have a lifetime of 4 hours. I
> plan to isolate all of the things that require tickets on a separate
> server that we can watch more closely for security problems, and can
> restrict more thoroughly than the server we're currently running things
> that don't require a TGT on.
There are two problems I can think of with this scheme-
1) you need to keep an extra daemon running to manage the cookies
2) because the cookie is just a random string if someone out there
manages to steal it using a hole in the various web browsers out
there, that person can have the same access as the real individual.
The method I'm using creates a string consisting of a random 8
characters, the authenticated individual's username, and the IP
addresses of the client and server. It takes the resulting string and
encrypts it using a key extracted from a srvtab on the server. The
final product is then sent to the client as a cookie.
When the client sends the cookie back to the server, the cookie is
decrypted, providing the username, so no daemon is required. In
addition, the decrypted IP addresses are checked to verify the cookie
hasn't been stolen.
As I mentioned previously, I am keeping the ticket files on the
server, though that is not a requirement for this scheme to work.
Ticket file/cookie lifetimes are adjustable via a resource.conf
directive.
Access to directories is controlled via .htaccess entries - here's a
sample:
UseUMDKrbAuth on
AuthType Basic
AuthName GLUE.UMD.EDU
<limit get post>
require valid-user
require user bart
require user marge lisa
require group staff
</limit>
Kevin
