Shibboleth Developers

[Tom Scavo <>]

A few questions below...

On Mon, 6 Dec 2004 14:59:29 -0500, 

<>
 wrote:
> 
> 1) We're trying to build off our understanding of how trust
> validation WILL work in the shib v1.3 IdP code.... we're presuming
> this will be a variant of how the shib v1.2 SP implementation
> implements trust validation......
> 
> the SP impl uses the IdP's providerId to find a match in the sites
> file, and uses the providerId or siteGroup name to locate keyInfo or
> keyAuthority elements  in the trust file. We're guessing that the IdP
> trust implementation might use a similar lookup sequence, but use the
> resource value rather than providerid as the initial input value.
> 
> 2) We're suggesting extending the IdP's RelyingParty element to allow
> new items to be specified:
> 
>         -- whether or not to use ARP processing (perhaps add an
> attribute to the RP element which names the associated
> ReleasePolicyEngine (which might be null...)
> 
>         -- whether or not to insert a HoK confirmation element into the 
> result
> 
> 3) The Resource value supplied by the LS client to the AA would be a
> static value,

Static over *all* LS clients?

> and would match against BOTH a RelyingParty element in
> the origin.xml file, and (in the trust file) the keyName value in
> associated with the signing cert used by local SASL-CA. This would be
> *strongly  recommended* practice, rather than something that was
> coded.

Sorry, which practice is strongly recommended?

> This would ensure that an LS client could make an attribute query
> that bypasses ARP processing ONLY by supplying a cert signed by the
> local SASL-CA. Presumably, this would ensure that it could only ask
> for attributes about itself.
> 
> NOTE: yes,this is hack -- if you match an RP that specifies NO ARP
> processing, you can only be asking for attributes about yourself......
> 
> Here's the suggestion for how this would work:
> 
> 1) LS client creates an SSL tunnel to the local AA; the LS client
> uses a cert obtained from the  local SASL-CA and containing a handle
> in the DN
> 
> 2) LS client sends an Attribute Query to the local AA; it contains a
> subject element with the same handle as found in the cert. The
> Resource value is just a static value, but must match as described in
> the next steps.
> 
> 3) the AA  matches the supplied Resource value against an RP element
> in the origin.xml file; this RP element is configured for LS
> processing, as described in Assumption 2 above.

Okay, I'll bite ;-)  What if you mostly skip step 3?  If the value of
the Resource attribute is a known LS URI, simply proceed with the
following steps.  I guess I'm missing something wrt Assumption 2.  Are
you attempting to generalize?

> 4) The AA validates that the handle in the cert matches the handle in
> the Subject element. (asking for attributes about yourself....)
> 
> 5) the AA does trust validation -- the AA looks for a match in the
> trust files, matching the Resource value against keyName elements. If
> that fails, the AA tries to match the Resource in the sites file,
> obtains the Name value from the enclosing siteGroup element, and
> looks for a match in the trust file, matching the siteGroup name
> against keyName elements. This should locate the cert used by the
> requestor, or the CA(s) that signed the cert used by the requestor.
> 
> The AA ensures that the supplied cert meets the criteria imposed by
> the trust file.
> 
> 6) the AA processes the request normally.....
> 
> NOTES:
> 
> 1) in  this description, the cert containing the Handle essentially
> becomes a long-lived Subject element..... however, it can only be
> used by someone possessing the matching private key.

What is the life a cert issued by the SASL-CA?  Is revocation an
issue?  (Evidently not...)

> 2) last week, Scott had mentioned the idea of some sort of policy
> language that would be used  to define "such and such a requestor can
> ask about such and such a subject"... *if* we understand this, then
> this policy processing would replace step number 4 above.....
>