Shibboleth Developers

["RL 'Bob' Morgan" <>]

> -- the other situation (which happens to be the one I'm playing with
> right now), is on the opposite end of the spectrum. Several applications
> hosted on the same machine, each serving smallish VO's.  And all having
> (roughly) the same session and attribute requirements.
>
> I could configure my shibboleth.xml file with a single Applications
> element (named default, let's say), and have all the hosted applications
> share this definition. This means they'd all share the same providerId
> value.

In which case you would be promoting that app-hosting service as a visible
accountable entity in the world, say "appfarm.brown.edu".  IdPs and their
users would set policies referring to appfarm.  Potential apps for it to
host would read the appfarm terms&conditions to see if they could live
with them.  If an app decided to move out of appfarm it would have to
decide whether to create its own name or live under someone else's
app-hosting identity.

> ... or I could decide to create/assign separate providerId's to each
> hosted application (each providerId containing the logical name of the
> application, or fred1, fred2, etc, if that's what I wanted). This
> approach would force me to create additional Host/Path elements in the
> mapping area, and point these to additional Application elements (each
> with its own providerId).

I would think in the normal case this would be closely related to (though
I guess technically distinct from) the decision of whether to represent
each of these apps as named (virtual) hosts, hence having to get a cert
for each, etc.  The reason we do that is to make that service name
distinct from the name of the underlying host, so it can change hosts
transparently if need be.  Same consideration with its Shib participation.

> As is often the case, I suspect there's no universal right answer, just
> a set of tradeoffs that have to be evaluated.

I'll say again that Shib/federation setup should be the tail, not the dog,
ie it should as much as possible be obvious what to do given the more
familiar naming considerations.

 - RL "Bob"