single sp and multiple sessions

[Ulrich Leodolter]

Hello,

On Sat, 2013-09-28 at 14:07 +0200, Peter Schober wrote:
> Had to postpone sending this yesterday...
> 
> * Ulrich Leodolter <ulrich.leodolter at obvsg.at> [2013-09-27 10:39]:
> > single SP and Apache running on one host my.domain.
> > two protected locations /shib/A and /shib/B which
> > require session with different IdP (IdP-A and IdP-B).
> > the SP has configured only the default application.
> > 
> > when i open https://my.domain/shib/A i am redirected
> > to login at IdP-A and login works as expected.
> > 
> > but when i open https://my.domain/shib/B in new browser tab
> > i am not forced to login at IdP-B,  the existing session from
> > IdP-A is accepted.  i only managed to deny access using
> > apache rules (Require shib-attr ...).
> 
> With a single application a session scoped to a single path (by
> default path=/) will be created, no matter what path (REQUEST_URI)
> caused the session to be initiated.

Thanks for clarification, now i understand the documentation at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationModel

> > is it possible to have one SP session for each path from a single
> > client(browser) when using this setup?
> 
> You could detect and handle this in case your application (compare
> existing identity with accessed resource and destroy the old session,
> initiating a new one via the other IdP), or with static access control
> (as you currently are doing), potentially with improved error messages
> using the SP's or the webserver's features.
> Or you can create two logical SPs, which will have seperate sessions,
> by using ApplicationOverrides. These SPs will also need to have
> seperate SAML metadata (i.e., they will potentially require additional
> attribute release configuration at any IdPs you currently federate
> with) and a unique handlerURL.
> 
> I think with a well-designed error page for HTTP 403s what you're
> currently doing is both simplest and most appropriate (informing the subject
> that the resource is not meant for/available to her.)
> If you want to get fancy and allow for the case of the subject also
> having an association with the "other" institution you restrict
> sessions to, you can offer a local logout link and initiate a session
> via the "other" IdP.

I would like to avoid any error message like
"shut down your browser and login again"

I modified our test SP and tried to keep the modifications at
a minimum.

...
<Path name="shib" authType="shibboleth" requireSession="true">
  ...
  <Path name="TST" requireSessionWith="obvsg" applicationId="TST" />
  ...
</Path>
...
<ApplicationOverride id="TST">
    <Sessions lifetime="28800" timeout="3600" checkAddress="false"
         handlerURL="/shib/TST/Shibboleth.sso" handlerSSL="false" />
</ApplicationOverride>

On our local simplesamlphp testing IdP i modified the SP metadata
and added one extra AssertionConsumerService to the existing SP
( .../shib/TST/Shibboleth.sso/SAML2/POST)

Everything seems to work, from my browser i can login twice on two
different locations.

As far as i understand the documentation this is one valid reason for
adding new applications.
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride


Any hard reasons why not doing it this way?


Best regards
Ulrich