|
|
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.
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 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
- 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
- returns an existing TID for a user-SP combination;
- generates, inserts into the table, and returns a new TID
if one does not exist and the DB is master; or.
- returns a NULL value if the DB is a slave.
- 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.
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]
|