IDENTITY AND ACCESS MANAGEMENT
[an error occurred while processing this directive]

TargetedID generation for shib version 2.x

Summary: This describes the method for used by the University of Washington to generate and maintain TargetedId attributes.

Capabilities of Shib 2.x make this task much easier than it was for version 1.3. In particular, we no longer have to modify or provide any shib code.

Download:
  1. Postgres schema
A Shibboleth TargetedID is an opaque string, unique to each user and service provider, that can facilitate long-term user sessions, but that cannot be used to identify the user.

Shibboleth does not provide a viable way to maintain TargetedIDs in a production environment. Our method stores TargetedIDs in external, Postgres databases. generating the values only as needed. Redundant databases, with automatic replication and failover, are easily achieved.

These requirements for TargetedIDs are commonly encountered.

  • The TargetedID should remain invarient between shibboleth version upgrades, major and minor. This is most difficult to achieve with the example method distributed with shibboleth.

  • The TargetedID should remain invarient if a Service Provider (SP) changes its name.

  • An collection of service providers (e.g., a service-provider-domain (SPD?)) may want to use the same TargetedID for the entire set of SPs.

  • A service provider may want to change a TargetedID for a single individual, if it was compromised, for example.

  • The TargetedID should have the same level of availability and redundancy as other components of the idP.

To maintain these TargetedIDs (TID) we use a Postgres database on each IdP system. These database servers are configured such that:

  • Any query for a TargetedID either retrieves an existing id or creates and returns a new id.

  • By design, the generated id will be the same on all systems.

  • Each IdP uses first its own database, with automatic failover to its peers' databases.

  1. Database Schema:

    The Postgres database maintains two simple tables: a list of relying partes; and the targeted ids of each user-rp pair.

    Table*Contents
    tgtidsone row for each user/relying party combination.
    regidour invarient user identifier (uwRegID).
    rpkeya unique key assigned by us to each relying party. (More than one RP could share a key)
    tgtidthe TargetID: (MD5 hash of a secret + the user + the rpkey)
    rps(generally) one row per RP.
    rpkeythe RP's key
    rpidthe RP's entity id

      * Selected columns only

    • The tables are linked by the common rpid attribute.
    • Records in tgtids and rps will be automatically generated if a TargetedID is requested and none exists.
    • See the schema details.

  2. Query and Update Functions:

    Stored procedures on the database either

    1. returns an existing TID for a user-SP combination;
    2. generates, inserts into the table, and returns a new TID if one does not exist.
    3. See the procedure details.

  3. Replication:

    Each IdP host maintains a tgtid database. Since they use the same secrets, their generated tgtids will be the same. Synchronization is needed only when the secret changes, when a specific entry needs to be deleted, or when an SP changes its entityID. An off-line process monitors peer databases and keeps the local copy up-to-date.

The system uses a relational database connector with the SQL statement

select tid('${uwRegID.get(0)}', '${requestContext.getInboundMessageIssuer()}')

  • Where the uwRegID is a unique user attribute.


[an error occurred while processing this directive]
Jim Fox
UW Technology
Identity and Access Management
University of Washington
fox@washington.edu
[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive]
Fox's Home

© 1983-2017, University of Washington