Shibboleth Developers

["Diego R. Lopez" <>]

> but, I'm concerned about whether we might see more and more campuses 
> bringing this level of skill and experience to a shib install, and 
> repeating the experience we've seen this week, and wondering how to 
> simplify this process......
> 
> might MD include functionality that would help with this process?
> 
> should we build some sort of specialized "inspector tool" into shib, 
> that we could connect to remotely? to validate the basic steps in an 
> install?
> 
> some other approach?

May be that not exactly for Shib installations, but I guess the piece
we are working on inside TF-AACE could be of some help. I have only some
whiteboard designs and lot of discussions with the guy who is beginning
to struggle with it, but I think it will be useful. I enclose the
proposal I circulated through the TF-AACE list. Since I presented it,
the group decided to try opening the proposal to a wider range of 
protocols (namely, XACML and SPOCP), so the system is now called AA-RR 
(pronounce it like a Neanderthal in front of his mammoth dinner), but
the proposal is essentially the same.

8<-----------------------------------------------------------------------

This activity consists in the definition and building of a SAML
requester/responder able to use some sort of metadata describing the 
requirements of a certain infrastructure in order to validate (or make 
at least an initial assessment on) the interoperability of a certain 
component with other(s). The SAML-RR will be built on the following 
assumptions:
 
1) There is a common consensus on using SAML as the lingua franca for
   AA interactions, not only in the middleware NREN community, but also
   in the industry (Liberty) and the Grid community (see the documents
   on OGSA and SAML integration referenced by David Chadwick).
 
2) SAML, as any other standard, leaves much open issues, so different
   profiles can be applicable to accomplish a certain task.
 
3) The number of different components, systems, APIs, etc. able to run
   into AA interactions seems to be much greater in the near future,
   as other application domains become aware of the available 
   technologies and their potential benefits. In many cases, existing 
   procedures or specific constraints will drive to the establishment 
   of "local" solutions that should be able to interoperate with
   national, international, or transnational initiatives.
 
4) These components are going to operate at different levels upon the
   netwrok infrastructure (and even inside), so many of the assumptions
   about software architecture, languages, etc. will not hold in a
   significative number of cases.
 
5) As it has been widely recognized (remember the BoF during last
   TNC in Zagreb), different infrastructures (supported by federations,
   virtual organizations, or whatever you name them) are going to have
   different requirements on which attributes and values are to be
   requested and/or enforced.
 
The SAML RR will be able to use external definitions to simulate the
external behavior of different components of several infrastructures
in order to assess the interoperability of a certain element with them.
Of course, the SAML RR will be able to learn of those elements it
connects to, enhancing its knowledge base.
 
There are three types of components that the SAML RR shall be able to
impersonate (please remember I'm trying to be agnostic with respect to
names. Any contribution to enhance naming will be really welcome):
 
1) Attribute sources (like a Shibboleth HS, a A-Select server, a PAPI 
   AAAS, or an Athens XAP).  These are, esentially, entities able to 
   accept SAML queries from entities of type 2) and respond with 
   attribute information.
 
2) Attribute Requesters (like a Shibboleth SHAR, a VOMS server, a PAPI 
   PoA, or a Athens DSP entry point). These entities perform requests
   about user attributes to entities of type 1) and make an
   authorization decision on them, possibly querying an entity of type
   3).
 
3) Authorization Engines (like Permis or SPCOP). These entities make
   decisions from the requests they receive from entities of type 2) and
   their internal configuration. They return a simple (yes/no) or 
   complex (for example, a SPOCP "blob") answer to the query.
                                                                              
  
In my understanding, the development of the SAML RR has to follow these
steps:
 
1) Define a (set of) SAML interoperable profile(s). This is something we
   more or less agree to do in the Amsterdam developer meeting, although
   not very much has been done. The profile(s) will be, at least, 
   applied to the SOAP/HTTP binding.
 
2) Define a way for describing and storing which profiles and attributes
   are required or provided by a certain component. I think we can
   either use RDF for this or take advantage of Peter Gietz's work on
   LDAP schemas.
 
3) Implement the requester/responder using openSAML (as also agreed in
   Amsterdam), and make it available (at least) as a SOAP service over
   HTTP.
 
The SAML RR will allow developers of new elements validate their
interoperability with the common profile and those particular
implementations available. I think this will be specially useful for
those people dealing with AA in environments somehow appart from
our common milieu: no Java, no Web servers, pure C and even real-time
constraints..., or the other way around: highly integrated environments
where several sources of identity/authority are to be used (the
word "metasearching", now very in fashion in some Internet2 lists,
comes to my mind).
 
A side effect, or it could be even the main result, is the applicability
of the collection of profile/attribute descriptions as a clearinghouse
for different community/federation/vo requirements, as requested at the
BoF on AA and attributes in Zagreb.
 
I can commit RedIRIS to do most of these tasks. We have just began a
joint activity with a Spanish university and it is our intention to
cover these issues. Of course, any direct contribution of any of you
will be very much welcome. Anyway, I expect your help in establishing 
the SAML profile(s) and defining the correct requirements for the 
components you are developing and/or using.

8<---------------------------------------------------------------------------

Enjoy,

-- 
"Esta vez no fallaremos, Doctor Infierno"
 
Diego R. Lopez

 
RedIRIS
The Spanish NREN
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------