This document hasn’t been peer-reviewed. Your mileage may vary!

1 Configuration Changes
- 1.1 Caveats
- 1.2 Starting Point
- 1.3 Changes
  - 1.3.1 Add the ComputedID Connector
  - 1.3.2 Add the new RelationalDatabase Connector
  - 1.3.3 Update any Dependent Settings
2 Reviewing Existing Data for Mismatches
- 2.1 Create a temporary table with salt
- 2.2 Compare the data

There are many reasons why you may be using the StoredIdConnector but may also wish to move away from it.

In moving away to a purely ComputedIdConnector you risk losing the existing persistent IDs that your users may be relying on to get access to resources.

Configuration Changes

It’s possible to configure the IdP to:

Check the existing StoredID database for a value and return it if present
If a value is not present, request one from the ComputedID generator instead

An approximation in pseudo-code:

stored_id = get_stored_value(user, service);
if is_defined(stored_id)
   then return stored_id;
   else return get_computed_value(user, service);

Caveats

This example uses SQLite as a target database engine for the (read-only) data set. Firstly because it’s really simple. Secondly, if you’re making this jump then no “new” data will be added to the database so the file can be statically deployed to your IdP nodes with no need to worry about another RDBMS and replication etc.

Starting Point

This assumes you have a working StoredID connector servicing requests for persistent IDs, for example:

<DataConnector xsi:type="StoredId" id="storedID"
        generatedAttributeID="storedID"
        exportAttributes="storedID"
        salt='%{idp.persistentId.salt}'>
    <InputAttributeDefinition ref="uid" />
    <BeanManagedConnection>sqlite-dataconnector</BeanManagedConnection>
</DataConnector>

This configuration will be happily producing values by first looking them up in the database, returning the value if it’s present and, otherwise, generating one, storing it and returning it. These values may be used for seeding SAML 2.0 persistent NameIDs or the new pairwise-id SAML Attribute.

Changes

Switching this basic config to the desired model… I’ve switched from the examples generating storedID to persistentId as it’s more descriptive.

Add the ComputedID Connector

<DataConnector xsi:type="ComputedId" id="computedId"
    generatedAttributeID="persistentId"
    exportAttributes="persistentId"
    salt='%{idp.persistentId.salt}'>
    <InputAttributeDefinition ref="uid" />
</DataConnector>

Be sure to use the same salt, which may be configured as a property elsewhere.

Add the new RelationalDatabase Connector

This new data connector will be queried first and will return an error if no results are available from the database. This signals to the resolver to try the Failover connector.

The SELECT statement looks up the required value based on the requesting Service Provider and the principal already. You may need to tweak this for your setup depending on what’s being used now.

Update any Dependent Settings

In this step, adjust any dependent Attribute Definitions or NameID generation properties to reference to new “persistentId” attribute.

Reviewing Existing Data for Mismatches

It’s possible to get the RDBMS to evaluate all your existing records and report which are wrong (in that if they were regenerated now, the persistentId would be different).

This process is specifically for MySQL but the general principle should port to other database engines (the function calls may be different!). I’ve also assumed that you’re using BASE64 and SHA1 so you may need to tweak the query for your specific circumstances.

Create a temporary table with salt

In creating a TEMPORARY table, the data stays in memory only, doesn’t persist outside of the session you’re using and isn’t written to transaction logs.

Compare the data

This query recalculates the persistentId for all existing records in the database and compares that with the one already in the database and only reports mismatches:

Shibboleth Knowledge Base

Moving away from StoredID