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

[Rich Megginson]

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!  ;)
>   
Have you investigated other Web SSO frameworks?  I'd just like to make 
sure we review the current state of the art, and not reinvent the 
wheel.  I don't know too much about it, but I do know there are things 
like PubCookie out there http://www.pubcookie.org/
> Cheers,
> Jason
>
>
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>   

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