Shibboleth Developers

[Tom Barton <>]

This thread leaves me confused as to what the criterion should be for 
the AA to permit release of an attribute, beyond what's in its attr 
release policies. Do we want to have assurance that the attribute is 
being released to the target so that it can perform a service for the 
user who is presently waiting for that service to be rendered? Or, do we 
want the design to inherently defend against a target that is abusing 
the trust invested in it by policy? Or ... ?

Shib v1 requires the user to pass nearby the AA to obtain a dated 
artifact of that occurance which the user gives to the target to use to 
get user attrs from the AA. This proof of presence is of the "guess a 
number between 1 and 2^n" variety, arguably undermined somewhat by how 
the HS is operated (eg, gives out the same handle for the same user 
every time).

Here are three approaches offered only to spur thinking about what 
degree of assurance the AA should be satisfied with. They are not 
realistic design proposals. (1) PKI ala Ryan's posting, or other 
modification of client software to enable direct communication between 
HS and client; (2) endow AAs with some type of logic for detection of 
errant behaviour of the external components with which it interacts; (3) 
include a "secured" xmpp/jabber server in the origin site architecture 
and require users to have their presence client up in order to receive 
shibbolized service (perhaps the AA would message the user, or perhaps 
the AA would verify the target's assertion that "user is active on ip 
address blah right now").

Tom

Scott Cantor wrote:
> > hmmm...  so currently the HS provides a "hard to guess, secret
> > value" to the target, and the target  uses this to refer to a user,
> > when retrieving attributes......
>
>
> Basically, yes. Mostly the AA is just a PKI-authenticated attribute
> service. The handle obfuscation is not really an access control
> mechanism for data release.
>
>
> > if the target doesn't have such a value, but does have publicly 
> > available information (eg a userid, a cert), is there a technical 
> > solution the AA can use to satisfy itself that this is a valid 
> > request? Or does it have to rely on policy (ie I know this SHAR,
> > and it has agreed to behave....)
>
>
> I don't think there's anything obvious. We *could* have chosen to
> include the SSO assertion as proof of presence (maybe we'll do that
> if SAML clarifies what you can really do with an SSO assertion), but
> taking that away, I don't see much is left, unless you involve the
> client. If you get the cert holder to sign something, then you've got
> proof of posession of a public key you could match up. Without certs,
> you could do it with Kerberos/GSS-API too, I suppose.
>
> -- 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--