Shibboleth Developers

[Scott Cantor <>]

> An origin site has a name that is a string but which we're 
> now recommending to be a URI so there is more possibility for 
> unique naming among distinct origins for a campus, each for a 
> particular purpose.

Yes, and this is <prefix>.siteName in the property file.

> At the origin side, the "Name of this Handle Service" is the param:
> 
>   edu.internet2.middleware.shibboleth.hs.HandleServlet.issuer
> 
> which is only needed, I think, so the HS code can find the 
> right cert/key to use, among those in the keystore, to sign 
> the authentication assertion. Yes?

It's strictly used to tell the origin code what to plug in to the Issuer in 
the assertions. The target reads that in for trust
checking purposes, but the origin really doesn't care what it is.

> And we choose to use DNS 
> names for this purpose since these names are widely used and 
> understood for naming SSL server certs.  A more comprehensive 
> approach would perhaps permit a DN in this slot, which would 
> be the complete Subject Name of the cert in question.

Yes, in fact it could be a DN now, but only if the target's trust list is 
such that an explicit cert is provided for that DN. If it
has to do cert path validation, then the target starts out with a CN or 
subjectAltName check, which is where we'd have to fix the
code to permit a complete DN match.

>  But ... now that I look at it, isn't this actually handled by these:
> 
>  # [Required] Keystore alias for the private key  
> #edu.internet2.middleware.shibboleth.hs.HandleServlet.keyStore
> KeyAlias = shibhs
> 
>  # [Optional] Keystore alias for the X509 certificate 
> (Defaults to the private key alias)  
> #edu.internet2.middleware.shibboleth.hs.HandleServlet.certAlia
> s = shibhs
> 
> which specifically tells the keystore which cert/key to use?

Yes, the origin is not capable of using different keys for different purposes 
unless you deploy two webapps.

> So:  is there really a need for 
> edu.internet2.middleware.shibboleth.hs.HandleServlet.issuer?

At the the moment, yes, since the origin has to know what to put in the 
assertions. It's like the policy/audience stuff in that
sense.

> On the target side, in the sites.xml file, there can be a HS name:
> 
>    <HandleService
>      Location="https://shib.cac.washington.edu/shibboleth/HS";
>      Name="shib.cac.washington.edu"/>
> 
> where again I think the only purpose of the name is in the 
> case where you want to have a key specific to that HS in 
> trust.xml, so you need to name it as a Subject.  Yes?  Is 
> there any other reason to have an HS Name?

Yes, it's also used to insure that if you rely on path validation to verify 
the cert used by the HS, that not just any cert issued
by those CAs can be trusted for that origin site. Lacking any X.509 extension 
or other OID in the cert, that was always explicitly
what we used that name checking for.

Of course, when we started, we planned on using Verisign, so we had to have 
it. I'm still personally in favor of it, and of course,
it's federation managed, really. Targets would rarely need to worry over it.

> Same questions apply to AA Name, at both ends ...

AA name is used for similar reasons, though it's for SSL server authn in this 
case, but as it happens, I never added any code that
actually checks it, so that would suggest it's not all that critical. ;-)

That's mainly an artifact of the original decision to send the AA info in the 
original assertion, and not use metadata to get it. So
the SHAR just trusts that if it requests attributes via a URL it got from a 
trusted HS, and libcurl says that it authenticated the
server ok (via a single CA list and the usual CN checking), that's good 
enough. It doesn't step in and cross check the hostname
against the Assertion issuer.

At some point, assuming I go in and replace the libcurl trust check with new 
code based on what I did elsewhere, I would probably
start checking that, again, simply to restrict the possible exposures.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--