eduPersonTargetedID - how is it constructed?
visser at terena.org
Tue May 20 04:12:34 EDT 2014
On 20 May 2014 07:26, Rod Widdowson <rdw at steadingsoftware.com> wrote:
>> The reason I'm asking is that I've recently had a case of an IdP that
>> moved from SimpleSAMLphp to Shib.
>> It seems that SSP and Shib use a similar way to generate ePTID (they
>> use a salt, entityid, and an attribute as input), but they're not
>> exactly the same. This causes the IDs to be different, so all accounts
> Just for information, is the SimplSAMLphp algorithm documented?
There is documentation on the use of it:
that doesn't cover the actual construction of the value.
around line 118 is the code:
$uidData = 'uidhashbase' . $secretSalt;
$uidData .= strlen($srcID) . ':' . $srcID;
$uidData .= strlen($dstID) . ':' . $dstID;
$uidData .= strlen($userID) . ':' . $userID;
$uidData .= $secretSalt;
$uid = hash('sha1', $uidData);
>> Any ideas?
> Nothing is going to be pretty.
> Two solutions spring to mind, depending on where your comfort is:
> - You could deploy the StoredID and prepopulate the database with the IDs
> that SSP would generate.
> - Or if you were brave you could code up the SSP algorithm as a scripted
> attribute. You might
> be able to persuade the IdP to consume php which would make porting easier.
I'm not sure I understand what you mean by prepopulating a database.
Does Shib IdP keep a database with users?
Maybe Peter can do a "Shib For Dummies" while having drinks today.
I'm thinking of patching SSP so that it accepts an optional
configuration parameter to generate the same ePTID as Shib does.
People migrating from Shib to SSP could then just flip this switch and
everything would be good.
Something similar should then be done for Shib to allow the other way.
Suppose this is done now-ish. People migrating will (hopefully) be
installing the latest version, so they will be able to benefit from
System & Networking Engineer
Singel 468 D, 1017 AW Amsterdam
More information about the users