<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Does uApprove give you the ability to compute the persistentId using a field other than the username?<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">We also reuse usernames, but our IdM system has a uniqueID# for every person that we use for cases such as this.<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">John<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 11:27 AM, Ramon Pfeiffer <span dir="ltr"><<a href="mailto:ramon.pfeiffer@uni-tuebingen.de" target="_blank">ramon.pfeiffer@uni-tuebingen.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
at our university, we are faced with the necessity of reusing usernames after a given timespan (several years). This means, some years after the account of user A has been deleted, the same username can be reused for a newly created user B.<br>
The persistentId is calculated by the uApprove plugin as salted hash over the SP, the IdP and the username. The SWITCH AAI strongly recommends to use a fixed salt for this calculation (see [1], section 11.1.3 (2)). Assuming user B registered with the same SP that was already used by user A, the persistentId for these users would be the same.<br>
<br>
We cannot be sure that an SP removed user A from his database after a reasonable amount of time. This faces us with at least two major problems:<br>
First, an SP querying for updates of user A's attributes (using an AttributeQuery and the persistentId) would get the attribute set of user B.<br>
Second, while logging in to the SP, user B is recognized as the same user due to both users sharing the same persistentId. User A could have saved data on the SP's datastore using his account that would then be available to user B. The SP could also have stored some user details (e.g. account balance) regarding user A. These would then be mapped to user B.<br>
<br>
A solution that we came up with was to change the salt used while generating the persistentId at regular intervals. A similar approach would be to use a random salt each time a new persistentId is calculated.<br>
However, this would conflict with the SWITCH AAI's recommendation. In case of a random salt, it seems deep reprogramming of the uApprove plugin would be needed, which is not an option.<br>
<br>
Did anybody experience similar problems? Any recommendations?<br>
<br>
Best regards<br>
Ramon Pfeiffer<br>
<br>
<br>
[1]: <a href="https://www.switch.ch/aai/docs/shibboleth/SWITCH/latest/idp/deployment/" target="_blank">https://www.switch.ch/aai/<u></u>docs/shibboleth/SWITCH/latest/<u></u>idp/deployment/</a><br>
<br>
--<br>
Universität Tübingen<br>
Zentrum für Datenverarbeitung<br>
<br>
E-Mail: <a href="mailto:ramon.pfeiffer@uni-tuebingen.de" target="_blank">ramon.pfeiffer@uni-tuebingen.<u></u>de</a><br>
Telefon: <a href="tel:%2B49-7071-29-70204" value="+4970712970204" target="_blank">+49-7071-29-70204</a><br>
<br>
<br>
<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br></div>