Assurance

[Russell J Yount <>]

In the section “4.2.5.5 SESSION AUTHENTICATION” it states.

If the IdP uses session-maintenance methods (such as cookies) so that after an initial

authentication act new Assertions can be issued without the Subject having to

re-authenticate, such methods shall use  industry standard cryptographic techniques to

ensure that sessions are at least as resistant to attack as initial authentication.

 

 

I could not find references on wiki.shibboleth.net as to how Shibboleth IdP handles sessions with enough details to point an auditor too.

 

Chad had responded to a question about IdP cookie protection on at at 2012-02-23 14:22:27 with:

The cookie isn't considered part of the public API so there isn't any documentation of it outside the code itself. That said, the protections in place are:
- normal cookie domain/path settings
- user-agent address checking
- cookie content signatures using a server-side, per-session secret key
- randomly generated sessions IDs

As far as I know, that's about all you can do for cookies.

 

How have others addressed this area? Would it make sense for the InCommon Assurance group to put some text together for a stock Shibboleth installation and perhaps for common add-ons such as the Ohio State Custom Login Handler which provides technical details that one could point an auditor to?

 

-Russ

 

Carnegie Mellon University