Shibboleth Developers

[Tom Barton <>]

Here are some basic requirements regarding a web based file service 
scenario, which appears to be the application of webdav that we are 
focusing on.

1. The server will store folder and file level ACLs which reference 
users and groups.

2. The server may want to retrieve and cache information about a user at 
session initiation to avoid the performance hit of retrieving info to 
evaluate ACLs with each attempted file access.

I suppose that the identifier to use in an ACL for users is settled - 
eppn. What about the identifier to use to refer to a group in an ACL - 
? Or urn:mace:origin.edu:localIdentifier? Is 
it clear that the server can/should parse "origin.edu" out of the 
identifier in order to know where to send a request? Does that in fact 
suffice to determine the origin AA? Is there any reason to constrain the 
semantics of this identifier to conveying group membership? Note that 
I'm putting off for some hypothetical future time the attendent 
implications for how origins should maintain local group membership info 
(or perhaps all person attributes!), ie, ala scoping in origin directory 
attribute values, presentation of membership info, etc.

The second requirement above results in the server needing to ask an 
origin site AA to list all of the user's group memberships. Are there 
any attendent technical or policy issues that haven't been hashed over 
before?

Would we rather just table group references in ACLs for now?

I know I haven't touched the basic question of how to arrange that the 
server and origin AA agree to exchange info about the user, but I 
thought it useful to examine other work that this use case might present 
to us.

Tom


 wrote:

> My question is -- how would we like shibbollized versions  of these
> to work?
>
> -- modify the webdav  client to do shib in some fashion?
>
> -- or, shib protect the webdav target, but have the target supply 
> something other than a handle to the AA, when requesting attributes?
> (eg cert, sort  sort of userid, etc)
>
> -- have the AA check out-of-band for "presence"  before releasing 
> attributes (eg jabber, etc)
>
> -- I  don't think its useful to say that the AA would only use the 
> default policy in this case -- presumably, that releases  only a bare
>  minimum of attributes,  and presumably something more than  that
> would be needed to access  protected webdav areas....





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

   http://archives.internet2.edu/

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