Shibboleth Developers

[Chad La Joie <>]

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

As the subject of this email suggest, this email is about the attribute 
resolver.  The component of the IdP configured via the 
attribute-resolver.xml file.

Following are my current plans of things to change/add.

- Move the source attribute ID that appears on some attribute 
definitions to the <Dependency> element.  This makes it clear from which 
dependency and dependency attribute the values are coming.  It also 
allows values from attributes with different IDs to be merged.  For 
example, if you have an LDAP database connector pulling in an attribute 
called 'eduPersonEntitlement' and a relational database connector 
pulling in 'epentitlement' you could list both data connectors as a 
dependency, with different source IDs, to a simple attribute definition 
and have their values merged together.

- Improve the relational database connector's connection pooling, in 
particular removing the behavior where a database is marked as dead. 
However, I'll probably move away from the current pooling library 
altogether because it seems to be a dead project and I don't feel 
comfortable relying on those.

- Support the conditional evaluation of attribute definitions and data 
connectors.  In some cases, some users have data connectors that may be 
very expensive to resolve and so may only want to use them if some 
condition is true.  This would allow for that.  The default behavior 
would remain as it is today but people could add a new, optional element 
giving an evaluation condition.

- Clean up the behavior of the principal and authentication method 
attribute definition.  Since a user can have multiple principals and 
authentication methods it's not always clear exactly what you'll get 
from these definitions.  My current thinking is to always use the 
principal and authentication method established with whatever relying 
party the IdP is communicating. For example, if you log in in to SP A 
with a username/password and SP B with a cert then, the username is the 
principal returned by the definition when communicating with SP A and 
the subject DN of the cert is the principal returned by the definition 
when communicating with SP B.  In the cases where a single 
authentication method might result in multiple principal names some 
means for selecting the right one will be necessary and I'm not yet sure 
what the best way to do that is.  Probably a precedence list.

- Add proper support for dependencies within <PrincipalConnector>s. 
Currently principal connectors can have dependencies but they aren't 
used with any of the supplied implementations.  So, the goal would be to 
provide an implementation that worked with dependencies such that, for 
example, the IdP could look up a principal name from LDAP based on the 
name identifier received.

- Collect, and make available, performance metrics for attribute 
resolution as a whole and for each of the three primary plugin types 
(attribute definition, data connector, principal connector).  Currently 
the only metrics I can think of are: length of time to do the 
resolution, whether the resolution failed.  Note, this has nothing to do 
with the audit logging, which is a separate thing.

I am also currently considering, but not committed to, the following items:
- Adding a resolver-level cache such that most (or all) of the data 
resolved for a particular principal would be cached for a configurable 
duration.  The difficulty with this is that some resolver data (e.g. 
transient IDs) can't ever be cached and some data connectors or 
attribute definitions might use data that could be reasonably expected 
to change from invocation to invocation.  I need to think more about 
whether the complexity of tracking all the non-cachable items is really 
worth the gains for doing it.  My current guess is that it's not and the 
proper place to do the caching is in the data connectors only.

- Convert most attribute definitions to scripts.  Currently all the 
definitions that ship with the IdP are compiled Java code.  If some one 
wants to tweak the behavior of the definition a bit it means creating a 
whole new attribute definition.  Converting everything to a script would 
mean that the deployer could copy the script file and make their changes 
and then just add a new Scriptlet attribute definition.  In addition, if 
there is a bug found in the attribute definition people could 
immediately "patch" the IdP by fixing the script file.  So, to me this 
feels like a "nice to have" feature even if it isn't used much.

And item that I thought about, be rejected, was:
- Making the attribute resolution process multi-threaded.  I rejected 
this because it would add a significant amount of complexity to the 
process and make it harder to track exactly what is going on.  In 
addition the Servlet container is already allocating at least one thread 
per-request. Additional pools of threads could result in resource 
starvation or unexpected interaction with the container.

--
Chad La Joie
http://itumi.biz
trusted identities, delivered