LinkedIn learning
Cantor, Scott
cantor.2 at osu.edu
Tue Jul 30 19:39:37 EDT 2019
On 7/30/19, 7:32 PM, "users on behalf of Lipscomb, Gary" <users-bounces at shibboleth.net on behalf of glipscomb at csu.edu.au> wrote:
> The only thing that comes to mind is that you can't encrypt assertions.
You are correct, sorry for that omission. I have the encryption optional property on, so I no longer pay much attention to that once I deploy and test for vulnerabilities. If you prefer to deal with that manually, then yes, you'd have to address that setting, though I would do it with metadata these days, not an override.
> In Lynda we used EduPersonTargetedID as the unique identifier. This wouldn't convert to LinkedIn Learning (and we
> don't use it anywhere else). As part of the migration we got LinkedIn to update the Lynda record with the new uniqueID
> so all history from Lynda would be carried across to LIL.
They tend to claim they won't do that during the migration, but if you pressed them I'm not surprised they would do it.
I should also add that in my testing just now, they also have corrected a bug and it now does fill in the mapped employee ID for existing records that don't have one but match for login on email, so it's not strictly necessary to upload the IDs by hand unless you need to prevent race conditions with email changes in the interim.
-- Scott
More information about the users
mailing list