Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Tue, 25 Jan 2005, Jim Fox wrote:

> 1) The targeted id must remain invariant between shibboleth
>   version upgrades, major and minor.  Clearly this is not so easily
>   achieved at present.
>
> 2) The targeted id should remain invariant 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.

Let me observe that the solution to requirements 1-3, which is to provide 
a mapping from SP identifier (whether sharname in 1.1 or providerID in 1.2 
and future) to some indepedent fixed value, is not related to whether the 
tgtid value is calculated or stored.  For requirement 4, obviously a 
per-user indication of some kind has to be stored to indicate that this 
user's tgtid is not what it used to be; but that could also be an input to 
a hash (just a small integer perhaps) rather than the tgtid value itself.

So a tgtid implementation could avoid storing lots of tgtids by still 
relying on calculating them based on some function of 
{service-provider-input, user-id, serial-number} where serial-number would 
be changed each time the user's tgtid had to be changed for some reason 
(presumably a fairly rare event, with a default value not requiring 
per-user storage), and the service-provider-input is determined by policy 
based on SP identifier.

One potential benefit of the stored-value approach vs the calculated-value 
approach is that it is easy for the IdP to map from the tgtid to the user 
entry if that's needed, say if the SP reports abuse by a particular tgtid, 
or wants demographics.  This might not be much of a benefit if the 
calculated tgtid can be got from IdP log files.  Another potential benefit 
of storing the tgtid is that its presence indicates that that user 
authenticated to that SP, but again that is also probably in log files.

One feature possible with the stored approach that would be hard to get 
with the calculated approach is providing multiple tgtids for a user to 
the SP, which might be useful in some transition scenarios (say an SP 
merges with another or something).  But this seems like an edge case.

Another feature of the stored approach is that you could jam values into 
those slots if you had to for some reason, eg to work with an SP that had 
lots of existing tgtids for your people (maybe some other IdP merges with 
yours or something).

But I have to admit that the stored approach makes me nervous since it 
means that a potentially really large database (number_of_users * 
number_of_SPs_that_want_tgtids) has to have fast enough response not to
slow down the attribute delivery process and has to be available to all
AA instances.  It would be hard to twiddle with (say bulk 
imports/exports/mods for whatever reasons) since it would be used, and 
potentially modified, on every authentication.  So I think the calculated 
approach is more robust, even though somewhat less flexible.  A really 
nice implementation might permit choosing between these on a per-provider 
basis.

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

The ER model here is fine, but I think a better term is needed for the new 
concept here, which is really a domain of targeted IDs that is made 
applicable to one or more SPs (as defined by SAML).  So maybe 
"targeted_id_domain" or "service_provider_domain" or something.

 - RL "Bob"