Shibboleth Developers

for this afternoon's conf call......

Let's start with a few assumptions:

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

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.

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.

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