Passing application context from IdP back to SP

[Andrei Remenchuk]

I am building web server which works as Shibboleth SP for multiple 
independent organizations. Each organization uses its own separate IdP.
We're using Native SP module in Apache and I'm isolating organizations 
by having multiple <ApplicationOverride> sections and 'applicationId' 
values for different web server paths, which correspond to those overrides.

That works fine to the point that IdP authenticates for us and releases 
attributes. After successful authentication, IdP redirects the browser 
back to organization-specific path at our SP, however at that point, 
application ID is lost, and even though valid Shibboleth session exists 
(judging by cookies, environment vars and output of /Session), that 
session has default application ID and not the organization-specific ID. 
"requireSession" in organization-specific <Location> does not recognize 
this session, and therefore sends the browser back to IdP, creating 
endless redirection loop.

For example, I have this per-path configuration in shib.conf:

<Location /org1>
   AuthType shibboleth
   ShibRequestSetting applicationId org1
   ShibRequestSetting requireSession 1
   ...
</Location>

<Location /org2>
   AuthType shibboleth
   ShibRequestSetting applicationId org2
   ShibRequestSetting requireSession 1
   ...
</Location>
...

And in shibboleth2.xml on SP, I have these overrides:

         <ApplicationOverride id="org1">...
                 <SSO entityID="https://organization-1-idp"...>
                   ....
         </ApplicationOverride>

         <ApplicationOverride id="org2">...
                 <SSO entityID="https://organization-2-idp"...>
                   ....
         </ApplicationOverride>

So, these multiple logical SPs share as much as possible, including 
common metadata, but I need to process them separately, so that when 
redirect comes back to my site, I know for which application it is. Even 
though the browser goes to correct IdP and redirect from that IdP lands 
at organization-specific path (/org2 for example), native SP throws away 
application ID at that point for some reason which I don't completely 
understand.

I have managed to make it work by overriding handlerURL in application 
overrides:

         <ApplicationOverride id="org1">...
                 <SSO entityID="https://organization-1-idp">
                 <Sessions .... handlerURL="/org1/Shibboleth.sso" .... >
         </ApplicationOverride>

This works and does what I am trying to achive, however that requires me 
to declare these handlers in SP metadata as separate 
AssertionConsumerService entries, in addition to default consumer service:

     <!-- common ACS -->
     <md:AssertionConsumerService 
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Location="https://my-service-provider/Shibboleth.sso/SAML2/POST" index="1"/>
     ...
     <!-- ACS for organization 1 -->
     <md:AssertionConsumerService 
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Location="https://my-service-provider/org1/Shibboleth.sso/SAML2/POST" 
index="1"/>
       ....
     <!-- ACS for organization 2 -->
     <md:AssertionConsumerService 
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Location="https://my-service-provider/org2/Shibboleth.sso/SAML2/POST" 
index="1"/>
       ....

The problem is that we want to provision organizational entries 
dynamically and give all different IdPs single fixed metadata for our 
SP, ideally without any organization-specific details built into it and 
without hard-coding any paths. We don't want to deal with virtual hosts 
either. Is that even possible ?

Are there any ways to cleanly share single common 
AssertionConsumerService between different applications and preserve 
application context ?