Linkedin learning
Wessel, Keith
kwessel at illinois.edu
Thu Aug 8 18:10:17 EDT 2019
I've strongly hinted that they need to consider supporting encrypted assertions, and they claim they've added it to their roadmap.
I've also recently learned that they plan to soon make the metadata retrievable from a URL for those who wish to dynamically reload it in their IdP. I strongly encouraged them to sign such metadata and make a signing cert securely available if they actually want to make this feature useful unlike some other vendors who I won't name here other than to say that they used to be earth's biggest bookstore.
I do wish they would include the OID-style names for first and last name and mail in the mappings they look for by default, but our tests show that those have to be added as custom mappings. I do give them points for paying attention to SAML2 names instead of friendly names, though.
Keith
-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Paul B. Henson
Sent: Thursday, August 8, 2019 4:56 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Linkedin learning
> From: mat houser
> Sent: Tuesday, July 30, 2019 12:24 PM
>
> I'm curious if anybody has gotten linkedin learning SSO working
> properly with the Shibboleth IdP.
We recently migrated from lynda.com to linked in learning. Other than the already mentioned annoying backpedal from federated metadata to ad hoc metadata (they say it's "more secure"), and the caveat that encryption must be disabled it was fairly straightforward. I believe links to the documentation have already been posted; I did have some confusion as to whether not they wanted the "friendly name" for the attribute or the urn -based name, when I initially put the wrong one I did get the same error as you. As I recall I had to put the urn.
Also, another annoyance the documentation doesn't really discuss well; they really really really really really try to encourage new users to link their linked in learning account to their linkedin.com account. The latter intentionally does not support SSO (they say for security reasons 8-/, they don't want an employer to be able to hijack and employees linkedin.com account; who uses their work account for their primary linkedin.com access???). If the two accounts are linked, after you authenticate via SSO, you then need to provide your local linkedin.com username/password before you actually get in. This is very confusing for people who do SSO and then immediately see a username/password prompt :(.
--
Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | henson at cpp.edu California State Polytechnic University | Pomona CA 91768
--
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
More information about the users
mailing list