Shibboleth Developers

[Jim Fox <>]

>  We'd like to ask people to review this document, and provide
>  comments and feedback via email.  Shibboleth 2.0

On those points where I don't comment I mostly agree with
the roadmap.



> > Identity Provider
> > Enhanced installation, deployment, and manageablity features:

Drop the WAYF and InQueue from the installation documentation.
They only complicate initial installs and are rarely, if ever,
used in real life.  Especially for beginners, point-to-point
authentication between an idp and an sp would be much simpler
to understand, configure and debug.  If someone wants to join a
federation (not InQueue please) later on - that upgrade is about
the easiest thing in shib-land to do.



> >  Enhanced support for deployment within a clustered environment

Is the IdP part of this a continuation of Chad's extension from
last year to support artifacts on a clustered IdP?  That works well,
but uses JBoss, which Oracle might be buying soon.  Shibboleth could
end up either supporting a custom version of JBoss or else requiring
the separate installation of a commercial package of unknown cost.



> >  Simplified creation of ARP rules that apply to multiple Service Providers

If you mean scripts or programs that will generate an arp.site.xml
from a database of SPs and rules this is a good idea.  If you mean
on the other hand to modify the xml schema to support multiple
SPs in a single Rule element this seems less useful.  Most production
sites either have or will have automatic tools to generate the arps,
so a Rule per SP is not really a difficulty.




> >  a data connector that will allow scripts to be used
> >  to generate and manipulate attributes

Do you mean:

  1) A new scripting language supported by shib?

  2) External "exec'd" programs?

  3) Fastcgi style pipe or socket connections to persistent scripts
     or programs?

  4) Scripts as Java classes, that could be dynamically loaded by shib
     to do attribute manipulation.

(3) is clearly better than (2), as it provides the same functionality
with better efficiency.  (4) seems most versatile, as the passing
of attributes back and forth would be much more conveniently
and securely.




> >  New eduPersonTargetedID implementation that supports
> >  database/directory backend

Why implement ePTID at all?  You don't generate any other attributes.
If I want to send ePPNs I have to create and manage them myself.
Shib will only look them up in SQL or LDAP or wherever and send them
to an SP.  Same with affiliations, and entitlements.  Why pick the
simgle most difficult to implement attribute and decide to
manage that one?  You're going to end up supporting a DBMS and
its installation and configuration as well.

One of the reasons for the new 'script' connector, I would think,
is to support just this sort of complex, installation dependent
attribute.



> > A fully functional, production quality, WAYF

A WAYF may have a place somewhere, but its utility is overrated.
Most service providers will continue to implement their own 'wayf'
functionality in their own way.




Otherwise, good plan.

Jim