Shibboleth Developers

I found this posting useful, as it forced me to go back  and 
re-examine our definition of a Club - what is it,  what does it 
provide,  what  does it require, and what  constraints might  it 
impose. The idea of a Club is out of scope for the architecture (and 
rightly so); a search thru v5 of the arch doc for the word club turns 
up zero  hits. The web site does have a draft Club  Shib Guidelines 
doc, tho 
(http://middleware.internet2.edu/shibboleth/docs/draft-internet2-mace-shibboleth-club-shib-guidelines-01.txt). 
That doc includes this text:

> 1.1    Shibboleth Clubs in General
>
>     A Shibboleth club is a crucial part of the underlying trust required for
> function of the Shibboleth architecture.  A club is a group of
> organizations(universities, corporations, content providers, etc.) 
> who agree to
> exchange attributes using the SAML/Shibboleth protocols.  In so 
> doing, they must
> implicitly or explicitly agree to a common set of guidelines.
>
> The common functions a club must provide to be operational for its community
> include:
>
> a. A registry to process applications and distribute club membership 
> information, including the PKI components necessary for trust.
>
> b. Provision of a general means to acquire information on local 
> authentication and authorization practices for individual members of 
> the club.
>
> c. A set of agreements or best practices agreed upon within the 
> group on policies and business rules governing the exchange, use, 
> and population of attributes before and after transit.
>
> d. Completion of and decisions on open-ended architectural options, 
> including attribute semantics and definition and other 
> implementation-specific choices to ensure interoperability within 
> the club.
>
> e. Definition of how the WAYF service will be provided within the club.
>
> f. A means of establishing trust and a mechanism to communicate this 
> trust both in and out of band.

(Intentionally,this is not a  very onerous list.....)

In addition, I think there was always the expectation that any pair 
of sites within a Club,  or group of sites within a Club, could agree 
to  and use additional policy and requirements above and beyond  that 
specified by the club (maybe the Club's requirements serve as a 
baseline?). This would actually be enforced thru Attribute Acceptance 
Policies and Resource Manager policies. I suppose it might be useful 
to formalize somewhat the terminology we use to describe these 
informal  groupings; this posting  refers to them as  "sub-groups" 
and "sub-sub-groups".

But, my primary point is that the original model always presumed the 
existence of these kinds of  groupings, and provided  a way to 
implement  them. Consequently, when I  read Scenario's 1, 3, and 4 
"old-style" in the posting, I disagree pretty strongly with the 
statement that in each of these cases a new Club has to be formed. To 
me, these all seem  like bi-multi-lateral agreements built on the 
basic Club policy.   We probably should develop a document that does 
explicitly identify situations when  a new  club is required -- I 
think it would be a useful exercise for  us, in order to better 
understand what would trigger the need for a new  club. But, I think 
that Scenario's 1,  3, and 4 can ALL be handled by side agreements 
among the interested parties, without having to create a new club.

Re Scenario 2 (medical records), I tend to agree  with Bob that this 
is a problem for the application -- not something to be solved by 
creating a new  club.

The posting also says, at one point:

> This is a slightly more hierarchial approach, which proved challenging
> in efforts to widely implement PKI systems.

this really scares -- from the perspective of having to implement at 
the target a framework that could validate compliance with 
hierarchically defined policy. Talk about a road strewn with dead 
guppies.....

So, while I don't (yet) accept the scenario's  as showing  the need 
for a re-definition of the Club structure, I did think there were 
very interesting ideas  in the posting:

-- associating  context with an attribute query:

> Michael realized during the Shibboleth discussion at the Internet2
> Member Meeting that what is necessary is a way to specify a context
> within which a query is issued.  This would allow the query from the
> SHAR to be issued under one particular trust agreement, reducing the
> need for users to be able to do the qualification of a request as the
> components themselves grow more intelligent.

I think the offered scenario's  do support this requirement (without 
necessarily implementing it as  a separate club). Basically, this 
might mean that at the target someone can associate "policy" 
(probably represented by  a urn?) with a target url. A target website 
might contain  resources that are governed by different policy; this 
is how the target site would represent that situation. When a user 
attempted to access target url X, the SHAR  might send this "context" 
(or policy reference) back  to the origin. The  origin  could then 
decide whether  it can operate within that context (is this a  policy 
it is  aware of, and has agreed to?). Presumably, it should also  be 
possible for the target  to associate multiple  policies with a 
specific target url; to send  all of them back to the origin; and the 
origin  could  choose which policy it wants this  transaction to 
operate under. All  of this strikes me as a very powerful policy 
framework.

The scenario's also give us some insight into the breadth of 
functionality that  AAP processing will have  to offer.

Lastly, at the end, the  posting mentions:

> This also facilitates something that is not currently possible under the
> Shibboleth architecture; the pulling of specific attributes, and
> specifying precisesly which attributes a target needs to know

I seem to recall that  we  made an *explicit* decision  to not 
provide this functionality. Several  people felt very very strongly 
that it was very important to  separate the  process  of  acquiring 
the attributes from the setting and management of policy. In other 
words,that we should enforce  a very high wall, a one way transfer of 
information, between the SHAR and the RM. It was also noted that some 
existing RMs would NOT  allow the SHAR to ask for the policy 
associated with a particular resource.

There seemed to be two possible solutions  (actually, one  poor 
solution with two variations):

-maintain  the "list of required attributes  in  two places: the RM 
and a config file used by  the SHAR.

- maintain the  list in two places: the RM  and an error page 
presented to the user if  access is denied.

Back last May,  think we chose option two....

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

   http://archives.internet2.edu/

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