Linkedin learning

Cantor, Scott cantor.2 at osu.edu
Tue Jul 30 19:13:01 EDT 2019


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




More information about the users mailing list