Shibboleth Developers

["Rod Widdowson" <>]

It would be nice to get https://bugs.internet2.edu/jira/browse/SIDP-234
fixed as well.  End users keep on tripping over it..

> -----Original Message-----
> From: Chad La Joie 
> [mailto:]
> Sent: 02 June 2010 19:38
> To: 
> 
> Subject: [Shib-Dev] [IdPv3] Attribute Filter Work
> 
> STOP! Before reading the main contents of this email please be sure you
> have read this:
> http://groups.google.com/group/shibboleth-
> dev/browse_thread/thread/1fcab032218f8ffb
> 
> This email deals with items under consideration for the attribute filter
> engine in IdP v3.  This is the component of the IdP configured by the
> attribute-filter.xml file.
> 
> Following are the things I currently plan to change/add:
> 
> - Require an ID for all policies.  Currently it is optional and logged
> if available.  However, troubleshooting policy issues where people have
> not given IDs is a real pain.  So while the ID isn't truly necessary for
> any logic within the system, I now think it's necessary from an
> operational standpoint.  For existing deployments, during upgrading, a
> random ID will be generated for each policy without one.
> 
> - Implement a new filter plugin that can use information in an attribute
> query and metadata to determine if attributes should be released.  The
> general use case behind this is to allow service providers to ask for
> particular attributes and have the IdP release what they ask for.  The
> implicit assumption is that either other policies will be in place to
> control the release of truly sensitive data or that user-approved
> attribute release consent (e.g. uApprove) would be used.
> 
> - Provide, as performance metrics, the time it took for the entire
> filtering process as well as each individual policy.  Note, because of
> the way the policies work there is no way to provide metrics on how long
> it took for an individual attribute without a substantial amount of
effort.
> 
> Like with the attribute resolver, an option I am considering but not yet
> decided on is:
> 
> - Convert most/all existing filters to scripts.  This has the nicety of
> allowing the scripts to be tweaked.  If the scripting language can be
> compiled to Java code (and today, all the ones that come with the IdP
> can be) there is no performance hit.
> 
> Also, like the attribute resolve, an option I considered but have
> rejected was:
> 
> - Multi-threading the attribute filter engine.
> 
> --
> Chad La Joie
> http://itumi.biz
> trusted identities, delivered