Shibboleth Developers

[Walter Hoehn <>]

Hi,

The "edu.internet2.middleware.shibboleth.hs.HandleServlet.issuer" and 
"edu.internet2.middleware.shibboleth.aa.AAServlet.authorityName" 
property entries are used to populate the "Issuer" attribute on the SAML 
Assertion element in the HS Response and the AA Response, respectively.  
You are right in saying that the 
"edu.internet2.middleware.shibboleth.hs.HandleServlet.issuer" is not 
used by the HS to determine which certificate to use, this is decided 
based upon the keystore alias.  We could potentially pull the HS Issuer 
name out of the certificate instead of asking the user for it.

Currently the SHAR processing completely ignores the Issuer field.  The 
SHIRE processing, however, does two checks.  It ensures that the Issuer 
value is listed as a HS name in the sites file.  It also verifies that 
it can pull the value out of the end certificate that is sent as a part 
of the assertion.

The reason this is necessary is so that multiple sites can share the 
same trust bundles.  To make this work, we have to have a way to tie a 
particular site (and thus scope) to particular certs.  If we didn't do 
this, origin sites would be able to impersonate each other.  We don't 
have to do this for the AA because it doesn't sign anything... same 
concept, but instead of reading the name of the AA out of the sites 
file, it comes from the HS and is used for SSL.

I guess we could do away with the separate names if we had certs 
containing the siteName.

-Walter

RL 'Bob' Morgan wrote:

> Just checking my understanding here, since I'm sure there will be
> confusion among deployers about what to name things.
>
> 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.
>
> 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?  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.  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.keyStoreKeyAlias =
> shibhs
>
> # [Optional] Keystore alias for the X509 certificate (Defaults to the
> private key alias)
> #edu.internet2.middleware.shibboleth.hs.HandleServlet.certAlias = shibhs
>
> which specifically tells the keystore which cert/key to use?
>
> So:  is there really a need for
> edu.internet2.middleware.shibboleth.hs.HandleServlet.issuer?
>
> 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?
>
> Same questions apply to AA Name, at both ends ...
>
> I ask because there are a lot of names to configure, and with pubcookie
> also we got into trouble with site/service/host/URL params that were
> apparently all the same, making people wonder.  I'm not suggesting any
> specific change here, but some of this might be made clear in docs about
> these params.
>
> - RL "Bob"
>
>
>  

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

   http://archives.internet2.edu/

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