Reused usernames and persistentIds

[Eric Goodman]

>> You can define which attribute is used as the input to the hash - you can make it username if 
>>you want, but equally you can make it any other attribute from any of your data connectors. 
>>Just change the sourceAttributeID value.

>I see this.
>Given it is such a bad practice to use the username (as mentioned by Scott), it shouldn't appear like >this on the wiki-page.

I'm not seeing the reference on the wiki that uses username...

But I'll clarify that while Scott's advice is critical for computedId, it shouldn't be critical (though probably remains recommended, as noted on the wiki) for the storedId connector.

The computedId connector generates a hash on the fly from an attribute, SP name and salt for EACH assertion to the SP. If at any time two different subjects use the same attribute value (e.g., reused user name) connecting to the same SP then you get a collision of attributes.

But the storedId connector generates the hash only on the FIRST assertion to the SP, and thereafter uses the stored value in the database. It should also check that the Id it generates is unique before asserting it. If a second user got the same attribute (username) value, the storedId connector should fail over into the "subsequent storedId" use case and generate a Type 4 UUID. 

I don't know enough about the storedId connector to claim that it actually successfully generates a separate ID if it gets an ID collision on create, but it certainly should.

--- Eric