Shibboleth Developers

At 1:46 PM -0400 7/16/04, Scott Cantor wrote:
>  > so there's  the balance point.... using logicalservicename makes
> >  reconfig easier if you move the service to another  host; it makes
> >  life a bit harder for the person managing the shibboleth.xml if your
> >  host is serving several applications with the same/similar session
> >  and attribute requirements.
>
> It doesn't change anything about using shibboleth.xml. I'm not following you
> here. There has never been any advantage to using a hostname in a
> providerId, they're just strings. Literally in fact, you could put "fred" in
> and it would work.

I'm  thinking of a couple of different situations...

-- a service which already has its  logicalname in the dns name used 
to access the service (eg dspace.osu.edu). In this case, the service 
presumably has a largish user community, is  highly visible, etc. In 
this case, it makes perfect sense to use a providerId  containing the 
logical name. There are lots of examples of services like this, in 
both the commercial and campus space.

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

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

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