LinkedIn learning

[Lipscomb, Gary]

The only thing that comes to mind is that you can't encrypt assertions.

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.

Regards
Gary

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, 31 July 2019 09:13
To: Shib Users <users at shibboleth.net>
Subject: Re: Linkedin learning

I'm in the middle of a lot of integrations so I don't have a lot of time but a quick brain dump if it helps:

- LiL will allow arbitrary attribute mappings but the core bits are the first/last name, email address, and if you want a stable internal/unique ID, that's mapped into what they call employee ID (so probably best to actually use your employee IDs if that's possible, or it's confusing for everybody)

- Pre-existing users from Lynda will not get the unique ID filled in at runtime via SAML but new users added real time in LiL will have that mapped value set.

- Based on my testing they will check for a match on that employee/unique ID value, and if not found, they'll fall back to an email lookup. That allows you to transition from email as a key to the internal ID once it's populated via CSV files for existing users.

- They don't update email address from the SAML login, but do update first/last name (don't ask me why)

- They do allow LiL-side authz if you set a mapping for an Attribute and attach an access rule to it that limits access based on it, so it's possible to use eduPersonEntitlement or the like to control access on the SP side

There's nothing special SAML-wise that I recall, certainly no need for a RelyingParty override or any unusual settings.

That's all I know/recall right now. We're scheduled to convert next Monday so if there are glitches I might know more then.

-- Scott


-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net