Shibboleth Developers

At 9:12 AM -0700 5/29/03, 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.

I'm using the sample files and assertions found here:

        
http://stc.cis.brown.edu/~stc/Projects/Shibboleth/Beta3-v1.0/SampleConfigs.txt

as far as I can tell, siteName (which has the URI value described 
above), only appears in the assertion posted by the HS as the  value 
of the NameQualifier attribute of the NameIdentifier element.

I don't know how the target uses this value......

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

again, looking at the "good stuff" found at that url, the HS seems to 
put the value of issuer into the Issuer attribute of the Assertion 
element.

In a conversation earlier this week with Walter, when I asked about 
the SHIRE's validation algorithm, he noted that it currently includes 
this logic:

        - get issuer value from the assertion

	- ensure there is an OriginSite element in the sites file 
whose HS element has this "name"

        - ensure issuer name = CN value in the end-entity cert

        - get site name (URI) from the OriginSite element

        - using site name, retrieve "CA bundle" from trust file

        - validate the signature on the assertion

So, issuer must match the CN value in the cert, and issuer must 
appear at the appropriate place in the OriginSite entry.

I haven't heard of any particular requirements imposed on the value 
of issuer.....

> And we choose to use DNS names for this purpose since these names
> are widely used and understood for naming SSL server certs.

That sounds like the right explanation.....

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



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

Its my understanding that the issuer value (HS name) is used to 
retrieve the associated OriginSite element; the siteName is retrieved 
from that element, and siteName is then used to retrieve the 
CA-bundle (which might be a key specific to that HS, or might be the 
set of CAs trusted by InCommon).


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

There also seems to be a lot of "rules" that once a particular value 
is chosen, it must be used in several different places on the origin 
and target.

I don't think this is currently spelled out in the deploy guides......

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

   http://archives.internet2.edu/

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