Shibboleth Developers

[Chad La Joie <>]

Oh, I also wonder if there should be an enveloping element around the 
attributes.  If another extension were to put attributes in the 
Extension it seems likely that you'd want to tell them apart and avoid 
collisions.

Chad La Joie wrote:
> To the extent that this is necessary I think the attributes expressed in 
> an Extension make sense.  I can understand the need for such attributes, 
> as you describe, but worry that people might abuse such a function and 
> try to place attributes common to an institution's user-base in here, 
> because it would be "easier".
>
> I do suspect you'd want an AAP for these attributes, that the 
> configuration of such an AAP would be easier to grok as a separate file 
> with the same syntax as the current AAP.  I'm not sure if a fixed prefix 
> is necessary, but having it would probably makes things a bit easier too.
>
> Ian Young wrote:
> > Speaking of metadata, I've been asked to try and get some discussion
> > going around an enhancement proposal I made earlier in the year, which
> > you can read about here:
> >
> > http://bugzilla.internet2.edu/show_bug.cgi?id=493
> >
> > For simplicity, I reproduce the text here, after which this message 
> > continues:
> >
> > > In very large deployments (I'm thinking of the UK production
> > > federation(s) here) it would be useful to be able to have the
> > > federation express, through its metadata, the contracts and other
> > > rules of engagement that the SAML entities are signed up to.  This
> > > would enable a situation in which different members of such a large
> > > deployment might be signed up to different agreements without each SP
> > > being responsible for collecting that information from the federation
> > > through some other mechanism and then re- expressing it in local
> > > policy files.
> > >
> > > I believe very large deployments can't practically have a homogenous
> > > policy environment: in the same way as authn at an IdP doesn't imply
> > > authz, mere presence in metadata can't imply much about entity 
> > > behavioural guarantees.  Automating the expression by the federation
> > > of the varying policies is going to be important for scaling, and it
> > > makes sense to regard this as something that the federation can
> > > assert through metadata in the same way as it currently asserts the
> > > valid scopes for an IdP.
> > >
> > > It would be sufficient to profile a Shibboleth-namespace metadata
> > > extension for IdP entities analogous to X.509 policy OIDs, and have
> > > some additional processing allowing policy URIs found in metadata to
> > >  be expressed to the Shibboleth-protected application through an
> > > additional CGI header.  However, Scott Cantor suggested that a more
> > > general facility would be the right way to go, and I concur.  This 
> > > would involve allowing standard SAML namespace <Attribute> elements
> > > to appear in an entity's <Extensions> element.  Such elements
> > > appearing in an IdP's metadata would be processed by the SP through a
> > > process analogous to the normal subject attribute processing and
> > > delivered in an analogous way.  Profiling an attribute to use within
> > > this scheme to express federation assertions about entity policy
> > > would be for definition elsewhere, as would any other application.
> > >
> > > It's not clear that attribute filtering makes much sense in
> > > (implicitly) trusted metadata, so that part of the chain might be
> > > omitted if inconvenient.
> > >
> > > A metadata-derived attribute X should not be delivered as equivalent
> > > to a subject-based attribute because they implicitly reference a
> > > different subject: they are attributes of the entity, not the user.
> > > So, an "email" attribute for the entity wouldn't be delivered in the
> > > same CGI header as an "email" attribute for the subject.
> > >
> > > One way to approach this would be to have a different AAP file for
> > > metadata attributes.  Another alternative would be to use the same
> > > AAP file, and mark metadata attribute clauses to distinguish them 
> > > from normal subject attribute clauses.  A third alternative would be
> > > to use the same AAP file, but automatically alter the header name for
> > > metadata attributes, for example by adding a fixed prefix.
> >
> > I should stress that although Scott gets credit here for generalising 
> > the original proposal, he isn't endorsing the use case.  The sheer 
> > scale of the UK deployment means that we're trying to address 
> > perceived scaling issues that just don't feature on anyone else's top 
> > ten list of things to worry about...
> >
> > Obviously, the business of defining attributes as extensions and 
> > embedding them in metadata is something that we could get on with 
> > without assistance from the developers.  To be really useful, though, 
> > the attributes need to be delivered to the application, hence the 
> > proposal above which would involve changes to the SP software.  (I 
> > actually think this concept is symmetric, but the uses are more 
> > obvious for IdP attributes being delivered to the SP)
> >
> > You could obviously use this facility in arbitrary ways, but I should 
> > give an indication of how we see it being used in the UK, at least 
> > initially.  We'd probably define a couple of attributes to say, 
> > approximately:
> >
> > 1. URI representing something the federation knows first-hand and can 
> > directly attest to.  For example, a particular class of membership of 
> > the federation; some membership classes may carry with them 
> > behavioural guarantees.
> >
> > 2. URI representing something the owner of the entity has publicly 
> > declared, but which the federation cannot attest to directly.  For 
> > example, a particular agreed set of identity management policies 
> > identified by a URI.
> >
> > You might call these "federation attests" and "federation relays", 
> > respectively.  The actual set of URIs defined for use with these 
> > attributes are of course a separate and probably quite contentious 
> > area for discussion.  I'd like to concentrate on the basic facility 
> > for now, though.
> >
> > So, as I say, if anyone has any feedback on this proposal - positive 
> > or negative - we'd love to hear it.  I guess the most important kind 
> > of response would be "this is far too evil an idea to ever be 
> > implemented, and here is why" but please don't feel you need to 
> > restrict yourself to those...
> >
> >     -- Ian

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124