Shibboleth Developers

[Rhys Smith <>]

General comment: all sounds excellent and very useful for people wishing to 
deploy multiple IdPs on a single piece of hardware. Thanks Chad!

More specific comments, inline below:

> 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)?


> 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?


> 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 :-).


> Obviously, doing this will require individuals to have a greater 
> understanding of their containers.  If deployers do not wish to gain that 
> understanding they may trade research time against dollars and buy more 
> hardware and each IdP just as is done today.

Personally, I don't think this is a problem - if you're going to be doing 
something complex like running multiple IdPs on a single piece of hardware 
for multiple ou/o's, you _really_ should know what you're doing...

R.
--
----------------------------------------------------------------------
Dr Rhys Smith                                   e: 

Engineering Consultant: Identity & Access Management  (GPG:0xDE2F024C)
Information Services,
Cardiff University,                            t: +44 (0) 29 2087 0126
39-41 Park Place, Cardiff,                     f: +44 (0) 29 2087 4285
CF10 3BB, United Kingdom.                      m: +44 (0) 7968 087 821
----------------------------------------------------------------------