Print

Print


We currently use ComputedIDs based on a hashed valued of of a unique 
identifier. We're in 2 minds over moving over to a StoredID. One one 
hand if we were to get a report of misuse from an SP where only EPTID 
and EPSA are released we currently have no obvious way of working out 
"whodunnit". On the other hand setting up a MySQL database just to do 
this does seem overkill, especially as you would either have to set it 
up multi-master if you have multiple IdP nodes or point all your IdPs at 
a single external DB server. FWIW we have implemented StoredIDs on our 
Test IdP with MySQL in a multi-master between them.

The EduPersonTargetedID appears to be calculated by some sort of hashing 
of a institutionally-provided unique ID, the entityID of the SP and a 
salt defined in the IdP config. It's probably pretty straightforward to 
write a function to do this "on-the-fly" providing you know how those 3 
are combined and the hashing algorithm used :-)


On 21/02/14 12:31, Dave Perry wrote:
> Hi John
>
> We setup our IdP 3 1/2 years ago and haven't gone down the 'store computed IDs' road. My guess is that is that it's just a different piece of work for the IdP to do, but it depends whether querying a database is quicker/less processor intensive.
>
> Dave
> _________________________________________________
> Dave Perry
> eLearning Technologist, Hull College Group
>
> Room L34 - Queens Gardens Library
> Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG
> Extension 2230 / Direct Dial 01482 381930
>
> ________________________________________
> From: Discussion list for Shibboleth developments [[log in to unmask]] on behalf of John Horne [[log in to unmask]]
> Sent: 21 February 2014 12:01
> To: [log in to unmask]
> Subject: Calculating attributes on the fly or use local DB?
>
> Hello,
>
> I am new to using Shibboleth IdP (2.4), but we are setting up two new
> servers for our site. Most of the work has already been done (mostly by
> contractors, a little tweaking by us).
>
> We have an attribute (eduPersonTargetedID/persistentID) which requires a
> calculated value similar to the 'computedID' attribute. Currently this
> value is calculated when first required, but then stored in a local
> MySQL database. On subsequent requests for the attribute, the MySQL
> database is used to look up the value (or so I gather. I've still to
> work out how shibboleth actually stores and retrieves the value).
>
> My question though is, is it worth using a DB to store/lookup the value?
> Is there any advantage in using a local DB? Would it not be a simper
> configuration to just calculate the attribute value on the fly (the same
> as 'computedID')? This also then avoids us having to maintain the DB
> (removing old records etc etc).
>
>
>
> Thanks,
>
> John.
>
> --
> John Horne                   Tel: +44 (0)1752 587287
> Plymouth University, UK      Fax: +44 (0)1752 587001
> Message scanned
>

-- 
/****************************

Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: [log in to unmask]

*******************************/

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.