Shibboleth Developers

[Scott Cantor <>]

> but I can certainly see Scott's  point...... and I now interpret 
> these two notes as recommending
> 
> https://brown.edu/shibboleth

No, certainly not. That's far too vague.

> So I'm wondering where the middle ground here is..... embedding the 
> host name into the providerId value leads to the problems Scott cites 
> above. Using something like
> 
> https://<application  identifier><domain>/shibboleth
> 
> would make target configuration more work, since Application elements 
> would now have to be created for each new providerId........
> 
> thoughts?

First of all, an "application" in the target sense of the word can only act
as one providerId, period. If you really want to act as multiple entities
(problematic in many respects as Jim as noted), you've set up multiple
applications anyway. The application stuff is not about this issue, it's an
internal organizational tool for session management, more than anything
else.

All I suggested is you use a name that has a more abstract meaning than a
hostname. I used this example a while back...if OSU wanted to export our
DSpace service to the world, but it was running on a box named "frobnitz", I
would use a providerId like https://dspace.osu.edu/shibboleth or perhaps
urn:mace:osu.edu:shibboleth:dspace

Of course, in reality, any real DSpace service would already have a reserved
alias in the DNS and wouldn't be accessed using a physical host name anyway.
So it goes with just about any commercial SP.

If I'm proposing anything, it's probably
https://<logicalservicename>.<subdomain>/shibboleth

-- Scott