... computedID works nicely as a fall-back when the database storing the ePTIds is down for maintenance  .... however this connector it is deprecated, and may not be available in future IdP releases.


On 21 February 2014 12:44, Peter Schober <[log in to unmask]> wrote:
* John Horne <[log in to unmask]> [2014-02-21 13:11]:
> My question though is, is it worth using a DB to store/lookup the value?
> Is there any advantage in using a local DB? Would it not be a simper
> configuration to just calculate the attribute value on the fly (the same
> as 'computedID')? This also then avoids us having to maintain the DB
> (removing old records etc etc).

If you:
- don't want to support revoking/giving out new ePTIds to users, *and*
- have stable identifiers for all your subjects that will never, ever
  change, *and*
- know neither your IDP nor any SP will ever change their entityID
then you can get by without storing them.

OTOH, if you're not sure you can prevent such changes (which may be
forced upon you by bureaucrats not caring about all subjects losing
access to their federated accounts/data, e.g. after a change of the
canonical DNS domain of the institution, which needs to happen
"everywhere", visible or not) you'd better have an abstraction layer
in between that prevents such changes from having adverse effects on
subjects and services.