Shibboleth Developers

[Scott Cantor <>]

> The initial comment says "Each party requires metadata from its opposite"
> and is true as far as it goes. I believe it will be helpful to new users to
> emphasize the opposite point, that the IdP and SP get their own
> configuration data from their own configuration files and from the
> configuration of the Web Server under which they run.

Fair enough.


> The Metadata that is
> given to others must match this configuration data. The IdP or SP will
> ignore their own entries in the Metadata file visible to them and will
> therefore not detect discrepancies between the Metadata describing them and
> the actual configuration.

Agreed. Maybe something to add and warn about too, to some extent anyway.

> Someone who encounters this code for the first time might imagine that if
> the Metadata file contains an entry for the IdP and is present in the IdP
> configuration that this information is used or at least checked.

It's been asked already, yes.

> Extending this point, it may be helpful if other specific comments relate
> Metadata describing me to the specific matching configuration elements.

Might be a good idea, but might also get pretty wordy.

> session. While dates and names in the Metadata certificate may be ignored by
> the SP, these same fields may be checked for validity by the runtime
> environment or library routines as they are presented in the copy of the
> same Certificate presented through XML or SSL.

That's simply not true in our code, and we took great pains to ensure 
that. What other people write is on them, but our code had better be 
consistent across all platforms on this point. I feel very strongly 
about that.

> Since in most cases the browser arrives at this endpoint through the WAYF, I
> think this comment needs to be expanded. If there is more here than just the
> Browser POSTProfile, then we need to describe it. When there is a WAYF
> involved, the SP often doesn't know this endpoint directly. 

POST vs. Artifact is the return path. Until 2.0, this is a GET.

Most SPs will need to know this endpoint, because external WAYFs simply 
don't work in a non-trivial system. Of course, they don't need to 
actually write code to read this data. My SessionInitiator code knows 
how to dispatch to the SSO endpoint if you tell it what providerId to use.

> Given conventional URL mapping to filters, this endpoint location strongly
> suggests a mapping to *.sso in a Servlet or ISAP world. I am very
> uncomfortable with trying to reserve any three letter file extension. Even
> if it isn't used for anything now, it may come back on us later. "*.spsso"
> or "*.shibbolethsso" seems safer. 

I could live with spsso. shibbolethsso is needlessly long. Since nothing 
in any wide use uses sso, I still think using it is fine. If somebody 
has a conflict, they can change it to whatever they like. This isn't 
part of the software. It's arbitrary.

> Things named SSO: Shared Services Outfit
> (http://eps.mampu.gov.my/sso/Home.asp).

Huh?

> Web File Extensions .SSO: SkillSoft NetPlay Courses:

Umm, double huh? Is this like supposed to be a common thing...?

> invoked by the
> browser via a MIME-type association.  The SCM MIME-type is
> "application/skillsoft-ocm", and the associated file extension is .SSO.  The
> download process is initiated from a Download button on the course summary
> page (coursenumA1.htm).  

If this is an IANA registered MIME type, then I will most definitely 
change my default. Otherwise...

-- Scott