Multiple IDP Entity IDs with 1 IDP

[Roy Spectech]

Shib-List,

Having re-re-read this:


https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride


We in a similar situation as Sunil, but we have to use pathways in the
hosted application:


Each customer has a section in the application vhost:

#
   <Location /customer1/login>
        AuthType shibboleth
        ShibRequireSession On
        require valid-user
        ShibUseHeaders On
   </Location>
#
   <Location /customer1/test>
        AuthType shibboleth
        ShibRequireSession On
        require valid-user
        ShibUseHeaders On
   </Location>
#
#
   <Location /customer2/login>
        AuthType shibboleth
        ShibRequireSession On
        require valid-user
        ShibUseHeaders On
   </Location>
#
   <Location /customer2/test>
        AuthType shibboleth
        ShibRequireSession On
        require valid-user
        ShibUseHeaders On
   </Location>
#



The reason we are leaning towards Overrides is that each customer has their
own IdP service,
some have required client-side CERTS, many have custom attribute mappings,
and some have different Session requirements.

Also as the vhost lines suggest, each customer has a real "login" area
(production) and a "test" area (development).
All of our customers want different access levels on those areas.




So we were thinking of something like this:


<ApplicationOverride id="customer1">
    <Sessions lifetime="7200" timeout="3600"   <<====================
CUSTOM TIMEOUT
        handlerSSL="true"
cookieProps="; path=/customer2/login; secure; HttpOnly"/>
    <MetadataProvider type="XML"
        uri="https://idp.customer1.com/Shibboleth.sso/Metadata"
<<==================== CUSTOM  IdP (meta provider from customer)
        backingFilePath="/etc/shibboleth/customer1-idps-metadata-saml2.xml"
        reloadInterval="7200" maxRefreshDelay="86400">
    </MetadataProvider>
    <AttributeExtractor type="XML" file="customer1-attribute-map.xml"/>
<<==================== CUSTOM attributes (mostly group access)
    <CredentialResolver type="File" key="customer1-key.pem"
certificate="customer1-cert.pem"/>   <<==================== CUSTOM
CREDENTIALS
</ApplicationOverride>



Questions:

1) Since this override is really about a customer and not about us, do we
need a handlerURL (e.g. handlerURL="/customer1/Shibboleth.sso") for each
Override?

2) In many examples we have seen, each overrides section has its own
entityID. Is that required here? The "Base" URL for each customer will be
the same.

Just the path will be different:

  e.g.   https://ourlargeapp.company.com/customer01
  e.g.   https://ourlargeapp.company.com/customer02

[...]


We're new to Shibboleth and I guess I have to confess being a bit confused
about entityID.
We declare one in the <ApplicationDefaults> section:

                            applications.company.com

But that is about us. We made a metadata file for it and everything. All
the customers are from very different domains, etc. They have their own
IdPs.
Do they each need an entityID in the Overrides section? Wouldn't that imply
they each have to have their own Metadata on the SP somewhere?


3) Lastly, this configuration is SP only. We have no Discovery Service. We
do not even have an IdP server.
What should we use for <SessionInitiator> or SSO (default IdP). For us,
there really isn't one.

Can we just leave it out of the <ApplicationDefaults> altogether?


Many thanks folks!

-- RGS

==================================
Roy G. Specter
roygspectech8 at gmail.com
========================================


On Fri, Jul 26, 2013 at 4:13 PM, Peter Schober
<peter.schober at univie.ac.at>wrote:

> * bs_sunil <bssunil74 at yahoo.com> [2013-07-26 20:35]:
> > Thanks Peter. Yes I am good with one entity ID for both vhosts.
>
> Great.
>
> > - Have one or several metadata providers so that the single SP knows
> > -  all the IdPs in use. No application overrides.
> >
> > When you say metadata providers, I am assuming IDP supplied metadata
> > referenced like in         <MetadataProvider type="XML"
> > file="idpmetadata.xml"/>. Can you give an example like where I could
> supply
> > that info?
>
> I just said to add the metadata for all IDPs to your SP --this is not
> specific to and has nothing to do with vhosting or anythig else you
> asked about. The documentation clearly covers how to add metadata to
> the SP (e.g. using one or more lines like you post above, or using a
> folder or many other ways).
>
> > I do not have a discovery/wayn service. So I can supply multiple
> > metadata like file="idpmetadata.xml"
>
> Adding SAML metadata (describing IDPs) to an SP has nothing to do with
> IdP discovery.
> You said you wanted each vhost to always use a specific IdP (to work
> around having to do IdP discovery) and I already posted the Apache
> httpd directive how to do that.
>
> > - Have a single piece (one EntityDescriptor) of SAML metadata
> >   containing ACS URLs for /both/ testa.com/ and testb.com/ and give
> >   that metadata to the IDP.
> >
> > An example of where I need to do this (like in shibboleth2.xml?)would be
> > very helpful.
>
> No, with "SAML Metadata" I'm mean SAML 2.0 Metadata, as specified by
> OASIS.
> I had assumed that at one point you provided the IdPs with SAML
> Metadata describing your SP. If that is the case you'll need to modify
> that metadata so that both testa.com and testb.com are present in all
> AssertionConsumerService elements where only one of them is listed.
> (Since you said one entityID for both vhosts is enough that means you
> only have a single EntityDescriptor describing your SP to the
> IdPs. You just have to make sure both testa.com and testb.com are
> contained in that metatdata.)
>
> If you did not provided the IdPs with SAML 2.0 Metadata for your SP
> you'll have to supply the same information via some other method,
> specific to these IdPs.
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130805/eaa57c47/attachment-0001.html