entityID questions

[Lohr, Donald]

Thanks

On 5/26/20 7:12 PM, Cantor, Scott wrote:
> On 5/26/20, 6:45 PM, "users on behalf of Lohr, Donald" <users-bounces at shibboleth.net on behalf of lohrda at jmu.edu> wrote:
>
>> We have a non-production Shibboleth IdP server and I was able to get a working configuration to login via this non-
>> production Shibboleth IdP and a test instance of their application, using a "IdP Initiated" model.
> Just edit /etc/hosts locally, use your production entityID and key(s), and you don't need to fake anything, you get a full test of all changes any time you make them.

I inherited our production and non-production environments.  This is 
intriguing, as I will have to follow-up on this model.
>
>> On our non-production Shibboleth IdP it has a https:// url style entityID value that we made up when we build this
>> server.  On our production Shibboleth IdP, it has a urn:mace:incommon: style entityID value.
> You can test with the same exact configuration as production ideally.
>
>> I do not even know how to answer their questions as to why our production Shibboleth IdP has a urn: vs a https: style
>> entityID value.
> Well, it shouldn't, see above. To them it should be "the IdP", they don't need to know what's production or not.
My guess is, when they scrape a IdP metadata file and find the entityID 
data, they are only expecting to find a name value that begins with 
https://, but I do not know that for sure.  Other than the obvious 
differences in the IdP metadata file between our production IdP metadata 
and non-production IdP metadata, it was the entityID constructs that 
remained as a difference.
> I've never had any SP really ask, at least out loud. If you're asking for history, it's like lots of things, it "made sense at the time". It is fully compliant.
>
> Pros:
> - It avoids the need for URLs to "resolve" to something when they're names, not locations. It reinforces that it's a name and not a location, which is its purpose.
> - URNs are simply more stable generally when used correctly.
>
> Cons:
> - URNs are weird to people without the proper technical background.
> - Very, very occasionally one will find broken software that won't handle them (I never have, but know they exist).
> - The use of the InCommon nomenclature was a mistake in the same way the the "shibboleth" convention in URL entityIds in the software was, it's unrelated to the purpose of the name and creates problems when changes happen that render the original name inaccurate.
>
> I have no plans to change ours. Wish I could say we were #1, but I think UW was.
>
> The naming practices of the urn:mace:incommon arc are such that InCommon membership has nothing to do with the name being assigned, it's ours.
>
> I also use urn:mace:osu.edu extensively for minting identifiers, and I still prefer them to URLs.
>
> -- Scott
>
>

-- 
D o n a l d   L o h r
I n f o r m a t i o n   S y s t e m s
J a m e s   M a d i s o n   U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0