<div dir="ltr">Thanks for the response Chris.<div><br></div><div>I think there are some very valid points here.<br><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:13px">If the application is stateful, how can you exclusively delegate session management to mod_shib on logout first?</span></blockquote><div><br></div><div>There is a big depends here. By tightly binding the session management to shib this can be achieved. i.e. the session key is based on the NameID passed by Shibboleth. Therefore the session is only valid when Shibboleth is valid.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">When the user logs in a second time within the app session window, they will reconnect to an existing session in the app. </span></blockquote>
<div><br></div><div>I don't see this as a problem and in some scenarios is good usability. After all, in AWS you logout but whatever was in your basket stays in your basket.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:13px">This will reveal how well or poorly the in application session management is written. Why? If anything changes between logins within the app session lifetime (30min?) data will change underneath you(eg group membership, name, entitlement etc) that you use to grant privileges in the session instantiation step usually only done on login. It will not be re-evaluated on the subsequent login and you will break your security model for the app because it won't have the latest, most accurate info on the user from the most recent login.</span></blockquote>
<div><br></div><div>Agree. However I believe this is about overall architecture and design. One must clearly separate, and not compound, the responsibilities of authentication and authorisation. Shibboleth has the only say over whether a user is authenticated and what roles etc. that user has. A user cannot access the application unless Shibboleth says so. However the application must be responsible for enforcing authorisation (based upon the auth information) and interpreting how that is applied internally (e.g. only user with admin group can change the colour). Authorisation must always be done at the point of need. i.e. you do not pre-emptively grant privileges at logon and cache them in the session but assert on every request. This is simple to achieve as Shibboleth passes the group membership, name, entitlement etc. on every request to the underlying app. </div>
</div></div><div><br></div><div>Basically, as a golden rule, do _not_ cache stuff from the IdP/Shibboleth in the application. I'd consider this bad practice. </div><div><br></div><div>This way you can safely logout without killing you session as there is nothing in the session related to authorisation (name, group membership etc.).</div>
<div><br></div><div>Do you think the above approach covers these concerns?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 June 2014 12:52, Chris Phillips <span dir="ltr"><<a href="mailto:Chris.Phillips@canarie.ca" target="_blank">Chris.Phillips@canarie.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A question and some observations:<br>
<br>
If the application is stateful, how can you exclusively delegate session management to mod_shib on logout first?<br>
<br>
Mod_shib will always do the right thing for mod_shib but things like php's session management (or any other thing -- ruby, Python, cgi, perl etc ) will potentially retain a session of some sort and some form of it somewhere. When the user logs in a second time within the app session window, they will reconnect to an existing session in the app. This is not a shib problem but an app hygiene problem and reason to logout locally first and kill the session.<br>
<br>
This will reveal how well or poorly the in application session management is written. Why? If anything changes between logins within the app session lifetime (30min?) data will change underneath you(eg group membership, name, entitlement etc) that you use to grant privileges in the session instantiation step usually only done on login. It will not be re-evaluated on the subsequent login and you will break your security model for the app because it won't have the latest, most accurate info on the user from the most recent login.<br>
<br>
The theory of abstracting things away is healthy but in practice it sounds like to me that you need to logout of the app to allow session cleanup (remove memory/disk presence of a session) before redirection to mod_shib..<br>
<br>
C.<br>
<br>
/mobile_____________________<br>
<a href="mailto:chris.phillips@canarie.ca">chris.phillips@canarie.ca</a><br>
<div class="im HOEnZb"><br>
> On Jun 18, 2014, at 7:01 AM, "Peter Gillard-Moss" <<a href="mailto:pgillard@thoughtworks.com">pgillard@thoughtworks.com</a>> wrote:<br>
><br>
> We do this with a hyperlink to /sso/Logout (which goes to mod_shib). We are trusting that Shibboleth 'does the right thing' here and expires the session.<br>
</div><div class="HOEnZb"><div class="h5">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><span>Peter Gillard-Moss</span></div><div><span>Developer | ThoughtWorks | TechOps</span></div><div><a href="http://www.thoughtworks.com" target="_blank">http://www.thoughtworks.com</a></div>
<div><br></div></div>
</div>