Shibboleth Developers

[Jim Fox <>]

The process of setting up a production shiobboleth IdP brought into
focus, for us at least, some serious problems with the distributed
method of eduPersonTargetedID generation.  Judging from USC's recent
problems with targeted ids I'd say we are not alone.

There appear to be several unstated and unmet, yet seemingly obvious,
requirements for a targetd id:

1) The targeted id must remain invarient between shibboleth
   version upgrades, major and minor.  Clearly this is not so easily
   achieved at present.

2) The targeted id should remain invarient if a service provider
   changes its name.

3) An entire shib'd client (e.g., a corporation) may have many
   service providers (applications at different domains) and may
   want to use the same targeted id for some or all of its SPs.

4) An client may want to change a targeted id for a single
   individual, if it was compromised, for example.


A couple of methods have been considered:

a) The distributed, compute-each-time method Has difficulty with
   requirement 1 and clearly fails requierements 2, 3 and 4.

b) Preloading targeted ids into a database, whether SQL or LDAP,
   seems to fail the 'in-practice' test.  In order to add an id
   to the user base one must generate a unique targeted id for it
   for each SP know to the IdP.  More difficult, in order to add
   an SP to the system one must generate and add a unique targeted
   id for each of the several hundred thousand users in the system.
   This would be a requirement even for those SPs added authmatically
   from InCommon or other federation data.


We are considering the following approach to overcome these
limitations and to satisify the four requirements.


First, setup an SQL database, mySQL in my testing, that contains
three tables:


  "users":  contains one row for each user/provider combination.

       columns =

         user_registry_id: an invarient string that identifies
                           our users.

         targeted_id: 128 random bits (by MD5), as a hex string

         provider_number: a unique number assigned by us to each
                         "customer", who may operate multiple SPs
                          wanting the same targeted id.


  "providers:  contains one row for each "customer", who may
               operate several SPs wanting consistent targeted ids.

       columns =

         provider_number: this customer's identifying number

         provider_name:  Text name of the customer

         provider_other_info: contact person, etc.


  "sps":  contains one row per SP.

       columns =

         provider_number: "customer" this SP belongs to

         SP_name; the SP's providerID, a uri or url.  In the code
                  this is often "requestor".


The tables are linked by the provider_number attribute.

We manually, or through our ARP GUI, maintain the "providers" and
"sps" tables.  Initially the "users" table is empty.


Second, we define a callable stored procedure on the database
that either 1) returns an existing tgtid for a user-SP combination;
or 2) generates, inserts into the table, and returns a new tgtid
if no entry exists.

Third,  we install a plugin, similar to the JDBCDataConnector, that
will perform a call to the stored procedure and interpret its results.

This method seems to answer all our concerns.  It is flexible, gives
a permanent record of targeted ids, and meets the requirements.

There are a few considerations, MySQL supports stored procedures
only since its 5.0.2 release (an alpha).  DB2 has supported them
for some time and might be a better database choice.  Also, I could
see no way to implement any of this without the custom plugin, and
I am not overly fond of this sort of customization.  It does, however,
work.

We are willing to contribute whatever part of this people might 
be interested in.  If someone wanted to review the code that would
be nice too.  I have some urgency here, as we will be releasing
these targeted ids soon.


Jim