[Freeipa-devel] Web SSO and securely storing the ccache

[Rob Crittenden]

Jason Gerard DeRose wrote:
> This is my proposal for how to implement the web-SSO that has been
> discussed a few times.
> 
> 
> Some background
> ---------------
> 
> We want a single URL (say /login) to be protected with modauthkerb.
> When a user successfully authenticates at the /login page, they're given
> a session cookie and their credential cache is kept in session storage
> on the server.  When a user visits a URL other than /login, we check to
> see if they have a valid session cookie: if they don't, they get
> redirected to /login; if they do, their ccache is retrieved and we use
> it to authenticate to LDAP on the user's behalf.  This will improve the
> performance quite a bit as the modauthkerb negotiation is pretty slow.
> We can also use this to provide SSO authentication to other webapps on
> the same server (although we shouldn't retrieve the ccache and make it
> available to just any webapp, only to ones that actually need it).
> 
> IPA uses the user's forwarded TGT to authenticate to LDAP, so minimizing
> exposure of the ccache is very important (otherwise if Apache is
> compromised, it could potentially authenticate to arbitrary services on
> behalf of the signed-in users).
> 
> 
> Proposal for securely storing the ccache
> ----------------------------------------
> 
> Once we start storing the ccache in the session, it becomes much more
> difficult to minimize exposure of the ccache, but I believe I have a
> workable solution:
> 
> When the user authenticates at /login, we create a random 256-bit
> session_key, which we send to the client as a cookie.  We then store the
> ccache in a two column session table, like this:
> 
>   primary_key          encrypted_ccache
>   ===================  ===========================
>   sha256(session_key)  aes256(session_key, ccache)
> 
> The session_key is needed to decrypt the encrypted_ccache, and only the
> client (browser) has the session_key, which it sends along with each
> request (as a cookie in the request header).  When a request is
> received, the server creates the primary_key by doing a sha256 hash of
> the session_key, with which it retrieves the correct encrypted_ccache
> from the session table.  Then the encrypted_ccache is decrypted using
> the session_key.  Lastly, the clear-text ccache is written to a
> temporary file (like in a tmpfs or in /dev/shm) just long enough to do
> the LDAP bind, after which the clear-text ccache is deleted.
> 
> We need to write the ccache to a file so we can bind to LDAP.  We
> currently bind doing something like this (in Python):
> 
>     conn = ldap.initialize(...)
>     os.environ['KRB5CCNAME'] = ccache
>     conn.sasl_interactive_bind_s('', _sasl_auth)
> 
> Us Red Hatters haven't found another way to do this, but if anyone else
> has a better idea, we'd love to hear it (we'd love to avoid the
> KRB5CCNAME environment variable hack).
> 
> Anyway, I believe this is a reasonable way to protect the stored
> ccache's from Apache while still allowing Apache to access (briefly) the
> ccache of the user whose request it's currently processing.
> 
> 
> Questions?  Comments?  Flame easy, I'm almost on vacation!  ;)
> 
> Cheers,
> Jason
>

How do we want to handle an expired TGT?

If my ticket expires in 5 minutes I can still log into the UI. I go grab 
a cup of coffee and a danish and come back 10 minutes later and start to 
work again.

The first LDAP operation will fail because the ticket is expired. Should 
we alert the user and redirect them, redirect to /login and see if we 
can somehow automatically re-try the operation or some other option?

Or should the entry point where we test the existence of the ccache look 
inside somehow to verify that the ticket is still valid within some 
threshold? I'm assuming that python-krbV will let us do that.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090710/88447560/attachment.bin>