|
|
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.
|
|---|
| Download: |
- 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.
- An RP record must exist in the rp table before any targeted ids will be generated or issued.
Database Schema:
The Postgres database maintains two simple tables:
a list of relying partes (rp; and the targeted ids of each user-rp pair (tgtid).
| Table* | Contents |
|---|
| tgtid | one row for each user/RP combination. |
|
regid | our invarient user identifier (uwRegID). |
|
rpno | a number assigned by us to each relying party. More than one RP entityId could share a number.
|
|
tgtid | the TargetID: (MD5 hash of a secret + the user's regid + the rpno)
|
| rp | one row per RP entityId. |
|
rpno | the RP's number
|
|
rpid | the RP's entity id
|
- The tables are linked by the common rpno attribute.
- Records in tgtid will be automatically generated as necessary and do not need to be preloaded.
- See the schema details.
-
Query and Update Functions:
The stored procedure on the database
either
- returns an existing tgtid for a user-RP combination;
- generates, inserts into the table, and returns a new tgtid
if one does not exist.
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 RP is added to the rp table.
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]
|