Skip to Content.
Sympa Menu

shibboleth-dev - RE: self service app to maintain Club Shib metadata, what metadata elements to access

Subject: Shibboleth Developers

List archive

RE: self service app to maintain Club Shib metadata, what metadata elements to access


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>
  • Cc: <>, <>
  • Subject: RE: self service app to maintain Club Shib metadata, what metadata elements to access
  • Date: Wed, 23 Feb 2005 09:48:29 -0500
  • Organization: The Ohio State University

> Perhaps the providerId should default to
>
> "https://idp.<shib-domain>/shibboleth"
>
> or
>
> "https://sp.<shib-domain>/shibboleth"
>
> for consistency.

I disagree. First of all, "sp" doesn't tell me what the SP is, and that's
bad for setting policy. Secondly, there doesn't *need* to be consistency and
suggesting there is sets a bad precedent, IMHO, and serves to confuse people
into thinking there does.

Names are names. They don't need to be anything but what they are, unique
names.

> The locations of the assertion consumer service endpoints
> might default to
>
> "<providerId>/SSO/POST"
> and
> "<providerId>/SSO/Artifact"
>
> but whatever you choose, please avoid "shire" in the location.

It's not that simple. There's a reason we use a fixed file extension, to
make it possible to explain how to configure the web server handler. With no
extension, it doesn't work at all. POST.sso and Artifact.sso might work, for
example.

Also, for 99% of cases, a single endpoint can and should handle both. It's
unnecessary to have two. The location shouldn't be used to "imply" what is
supported, that's the job of the metadata.

> So if you choose the providerId correctly to begin with, the endpoint
> locations fall right into place.

The two have nothing to do with each other. One is a name, the other is a
location.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page