Shibboleth Developers

["Howard Gilbert" <>]

Example-sites.xml

 

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

 

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.

 

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

 

One or more KeyDescriptors tell SPs how the IdP will authenticate itself. A single descriptor can be used for both signing and for server-TLS. You can place an X.509 certificate directly in this element to specify the exact public key certificate to use. The dates and other fields in the certificate are totally ignored.

 

I would like to add a note that when the IdP signs elements, it uses the Private Key included in its Credentials configuration element, and when TLS is used, the Server will use the Certificate and Private Key defined by the Web Server configuration file. An SP will then try to match the Certificates in the KeyDescriptors here to the ones presented in the XML Signature or SSL 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.

 

<!-- This tells SPs how and where to request authentication. -->

    <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"

          Location="https://idp.example.org/shibboleth/SSO"/>

  

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.

 

   <AssertionConsumerService index="1" isDefault="true"

Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"         Location="https://sp.example.org/Shibboleth.sso/SAML/POST"/>

 

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.

 

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

Web File Extensions .SSO: SkillSoft NetPlay Courses:

Launching SkillSoft NetDownload Courses

SkillSoft NetDownload courses are downloaded from the server to the client workstation, and may be played while offline.  In order to use the NetDownload function, the client machine must have already installed the SkillSoft Course Manager (SCM).  The SCM is a Java application, which is invoked on-demand by the user to play downloaded content, or 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).