Fox's UW Shib Page - TargetedID for shib 1.3

Fox's Pages

Updated: July 31, 2008

Fox's UW Shib Page - TargetedID for shib 1.3

TargetedID generation at UW for shib 1.3

Summary:	This describes a method for Shibboleth TargetedId maintenance using a Postgres database. Examples and downloads cannot not be expected to work without modification at sites other than the University of Washington.
Download:	You may consult the example components: Postgres schema JDBC connector patch, Database sync daemon,

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 databases. generating the values only as needed. Redundant databases, with automatic replication and failover, are provided.

Definititons

These requirements for TargetedIDs are consequential to its definition.

The TargetedID must 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 Attribute Authority (AA) system. These database servers are configured such that:

Only one of the databases (master) supports creation of new TIDs; the others (slave) are query-only replicas.
A single query either retrieves an existing TID; creates and returns a new TID (if master); or returns null (if slave).
The shibboleth AA queries first its local DB then each of the others, until it get a non-null response.
Automatic processes keep the slaves up-to-date and provide for failover on failure of the master.

Database

Database Schema:

The Postgres database maintains both the TargetedID information and the associations of service providers and their domains.

Table* Contents

tgtids one row for each user/sp_domain combination.

pno a unique number assigned by us to each provider domain (which may contain multiple SPs).

regid our invarient user identifier (uwRegID).

tgtid the TargetID: 128 random bits (from MD5), as a hex string

sp_domains one row for each provider domain.

pno the provider domain number

domain_name the provider domain's name

sps one row for each service provider .

pno the SP's provider domain number

spid SP's providerID

* Selected columns only

Table*	Contents
`tgtids`	one row for each user/sp_domain combination.
	`pno`	a unique number assigned by us to each provider domain (which may contain multiple SPs).
	`regid`	our invarient user identifier (uwRegID).
	`tgtid`	the TargetID: 128 random bits (from MD5), as a hex string
`sp_domains`	one row for each provider domain.
	`pno`	the provider domain number
	`domain_name`	the provider domain's name
`sps`	one row for each service provider .
	`pno`	the SP's provider domain number
	`spid`	SP's providerID

The tables are linked by the common pno attribute.
Records in tgtids and sps will be automatically generated if a TargetedID is requested and none exists.
Table sp_domains is advisory. Shibboleth's TargetedID functions do not use it.
See the schema details.

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 and the DB is master; or.
3. returns a NULL value if the DB is a slave.
4. See the procedure details.
Replication:
A background process on each slave system monitors the master and keeps its local DB updated with new SPs or TIDs. In loss of the master one of these processes will promote its DB to master.

Shibboleth data connector

A modified JDBC data connector plugin for Shibboleth version 1.3 allows the shibboleth AA to these databases. Modifications to the stock connector are:

Allow updates to the database, and
Allow the requester's ProviderID to be used as an attribute.
Query successive databases until a non-null result is obtained.

Database sync daemon

A daemon process, running on each database system, performs continual maintenance of the system.

The daemon for the master database logs each tgtid creation.
The daemon for each slave database watches the master for tgtid creation and updates its slave database. In the event that the connection to the master is lost the slave daemons choose one of themselves to become the new master.

These daemons also report the status of their database to the University's monitoring system.

Example

This example shows a TargetedID generated from the SP id and the user's registry id, rather that her userid.

Attribute definitions.

Note that the eduPersonTargetedID is now a SimpleAttributeDefinition.


  <SimpleAttributeDefinition
          id="urn:uw:dir:attribute-def:uwRegID"
          sourceName="uwRegID">
      <DataConnectorDependency requires="directory"/>
  </SimpleAttributeDefinition>

  <SimpleAttributeDefinition
          id="urn:mace:dir:attribute-def:eduPersonTargetedID"
          smartScope="washington.edu"
          sourceName="tid">
       <DataConnectorDependency requires="tgtdb"/>
  </SimpleAttributeDefinition>

Plugin parameters.

Note the use of the reserved attribute name Requester, which uses the requester's ProviderID, and the index on the dbURLs.



  <CustomDataConnector id="tgtdb" class="edu.washington.UWJDBCDataConnector"
       dbURL0="jdbc:postgresql://first_db_host/tgtids?user=user&password=password"
       dbURL1="jdbc:postgresql://second_db_host/tgtids?user=user&password=password"
       dbDriver="org.postgresql.Driver"
       maxActive="10"
       maxIdle="5">
       <Query>select tid(?,?)</Query>
       <AttributeDependency requires="urn:uw:dir:attribute-def:uwRegID"/>
       <StatementCreator class="edu.washington.DependencyStatementCreator">
           <Parameter type="String"
              attributeName="urn:uw:dir:attribute-def:uwRegID"
              nullMissing="false"></Parameter>
           <Parameter type="String"
              attributeName="%REQUESTER%"
              nullMissing="false"></Parameter>
        </StatementCreator>
   </CustomDataConnector>

Topics

Definitions
Database
Schema details
Shib connector
Database sync daemon
Example

Jim Fox
UW Technology
Identity and Access Management
University of Washington
fox@washington.edu

TargetedID generation at UW for shib 1.3

Database Schema:

Query and Update Functions:

Replication:

Topics