|
Fox's UW Shib Page - TargetedID for shib 2.x
|
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: |
- 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.
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 |
|---|
| tgtids | one row for each user/relying party combination. |
|
regid | our invarient user identifier (uwRegID). |
|
rpkey | a unique key assigned by us to each
relying party. (More than one RP could share a key)
|
|
tgtid | the TargetID: (MD5 hash of a secret + the user + the rpkey)
|
| rps | (generally) one row per RP. |
|
rpkey | the RP's key
|
|
rpid | the 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.
-
Query and Update Functions:
Stored procedures on the database
either
- returns an existing TID for a user-SP combination;
- generates, inserts into the table, and returns a new TID
if one does not exist.
- See the procedure details.
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.
Jim Fox
UW Technology
Identity and Access Management
University of Washington
fox@washington.edu
|
|
© 1983-2009, University of Washington
Fox's home