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

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:
  1. Postgres schema
  2. JDBC connector patch,
  3. 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.

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.

  1. Database Schema:

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

    Table*Contents
    tgtidsone row for each user/sp_domain combination.
    pnoa unique number assigned by us to each provider domain (which may contain multiple SPs).
    regidour invarient user identifier (uwRegID).
    tgtidthe TargetID: 128 random bits (from MD5), as a hex string
    sp_domainsone row for each provider domain.
    pnothe provider domain number
    domain_namethe provider domain's name
    spsone row for each service provider .
    pnothe SP's provider domain number
    spidSP's providerID

      * Selected columns only

    • 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.

  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 and the DB is master; or.
    3. returns a NULL value if the DB is a slave.
    4. See the procedure details.

  3. 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.
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.

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.

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>
    
    


    [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