Shibboleth Developers

[Chad La Joie <>]

Jim Fox wrote:
> > >  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.

I think this means two, inter-related things.  First, it means being 
very cognizant of where and how we store state in the IdP and, secondly, 
making sure we have the right APIs in place to allow people to plug in 
persistence/replication mechanisms at those points.  The HA-Shib code 
could be one of the means to do this and I hope a much cleaner version 
of this will make it into the IdP.  Even if it does though it will not 
be the only thing.  It's very likely you'll see a plugin(s) that allows 
you to use a database as the means by which this state information 
because available within a cluster.

All that said, let me be clear on thing about the JBossCache library 
that HA-Shib relies.  It does not require the JBoss Application Server 
nor would it be effected by Oracle purchasing JBoss (something I 
consider unlikely anyways) as it is open sourced.

> > >  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.

Option 4, the use of something like groovy or bsh or boo or jython.

> > >  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.

SAML 2.0 persistent identifiers when combined with NameID management 
protocols require support for this.  Like most of the rest of the stuff 
in the roadmap (hopefully) people will be able to plug in their own 
implementation of this if they don't like ours.  However, we get 
requests for this plugin probably more often than any other one with the 
exception of a more functional "echo" connector.

> > > 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.

That is totally okay, people are free to do that, in fact they already 
are, as you pointed out.  Having a WAYF available for people to use or 
use as a starting point for their own work, however, I think has merit too.

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