Shibboleth Developers

[Chad La Joie <>]

On 9/9/10 12:15 PM, Rhys Smith wrote:
> > In order to reduce the number of upgrades, you can share the actual
> > WAR between instances.  In most cases it will be one WAR for all
> > instances, but if you need to generate a custom WAR file for some
> > instances you can certainly do that. So upgrading N IdPs will
> > require M upgrades where M is the number of WAR files.  The
> > assumption is that M<  N, with M usually being 1.
>
> How does this impact upon having customised login pages? Would you
> need a separate WAR for all instances that require their own branded
> page, or could you have a single WAR but set the container to use
> different login pages for different instances (e.g. in the web.xml of
> tomcat)?

No, if you read a couple of the other IdPv3 emails you'll see that all 
the visible pages will be pulled out of the WAR.  This means the pages 
can't be JSPs, but one cryptic pseudo-markup language is probably not 
much different than another for most deployers.

> > Each deployment descriptor will allow you to bind your IdP to a
> > unique context on a given ip:port.  You may set up your container
> > to listen on more than one ip:port giving more "slots" to which
> > things can be bound.  So, if you have one ip:port you might have
> > IdPs bound to example.org/idp1, example.org/idp2, example.org/idp3.
> > If you have more than one ip:port you might end up with
> > example.org/idp1, foo.edu/idp1, foo.edu/idp2.  The unique entity ID
> > will still be set in the relying party configuration file, the
> > deployment descriptor just ensures you have unique endpoints for
> > all your IdPs.
>
> Fine. Just to double check - I presume "/idp1" "/idp2" "/idp3" are
> just examples you're giving and the actual postfix string/webapp name
> would be customisable per instance, presumably as a part of the
> deployment descriptor?

Yeah, those bits of the URL are known as the context name.  If you look 
at your container's docs you'll see how you can set that via the 
deployment descriptor.

> > Finally, the only resource intensive parts (that can be shared)
> > within the IdP are the metadata providers and DB/LDAP connection
> > pools.  These will be fixed up to allow them to be bound to the
> > container's JNDI tree and the IdP can look them up there.  Most, if
> > not all, the configuration options available via the normal IdP XML
> > config files will be available when configuring the component for
> > use with JNDI.  The configuration syntax will be different since
> > it's container specific.  And, if you want, you can bind multiple,
> > differently configured, instances of any given component to the
> > JNDI tree and have some IdPs use one instance and other IdPs use
> > another instance.
>
> Great. Anyone planning on hosting multiple IdPs for multiple
> organisations absolutely would require to be able to connect each
> instance to a different authentication/attr source. But I'm sure you
> know that :-).

Not necessarily.  I've heard some plans for people who want to host 
(virtualized) IdPs for primary schools.  In those cases, they claim, 
that the authn and attribute system is one thing for all schools they're 
talking to.  I guess it's maintained at the regional level or something. 
 But yeah, the idea is that each IdP would share as much, or as little, 
of their configuration as necessary.

--
Chad La Joie
http://itumi.biz
trusted identities, delivered