SURFconext cannot verify the configuration steps below as we are not a customer of this service provider. We have collected the information below from our connected instituions to the best of our knowledge. If you have remarks or tips you want to share, please send them to email@example.com.
Every institution gets their own instance of LinkedIn Learning. This instance needs to be configured by the institution. This is known as a Single Tenant Service in SURFconext. An institution needs to sign in with an account that comes with Linkedin Learning to configure an instance. SURF does not have that information, so the configurations is up to institutions. When done, the instance can be added to SURFconext by making use of the Service Provider Dashboard. See this page how to make use of the Service Provider Dashboard. Ask for access to the Service Provider dashboard by sending us a mail at firstname.lastname@example.org. This document describes how to do implement your LinkedIn instance for use with SURFconext. There is a well maintained manual available on the website of LinkedIn Learning how to implement Single Sign-On. Download this from the website of LinkedIn to get the most recent version. This page will highlight the SURFconext specific parameters.
Communicate to users that they have to use the option Sign In / Sign in with your organization account otherwise they will not be able to log in. At the time of writing LinkedIn Learning does not do automatic de-provisioning. LinkedIn expects this functionality to become available in 2020. Until then, this means that a license will remain linked for departed students or employees. Given the limited number of licenses, this means that yearly licenses have to be withdrawn from the accounts of those who left. On request you can use a CSV file to request the LinkedIn helpdesk to remove linked licenses.
The manual as made by LinkedIn can be found here. Please check the website of LinkedIn for the most up-to-date version. This manual is fairly extensive and should give enough information to configure the instance. Some changes need to be made to make it work with SURFconext. In this manual one thing is fundamentally different and needs to be taken into account: SURFconext acts as an Identity Provider to your LinkedIn Learning instance. If the manual refers to the IdP's metadata, entityID or something like a SingleSignOnServicelocation, the SURFconext metadata needs to be used. Let's go through the configuration. The administrator for your institution can configure your IdP to authenticate to LinkedIn Learning through SURFconext using SSO through integration with LinkedIn's enterprise platform. Before you continue, make sure you meet the following prerequisites on LinkedIn:
The first few steps of the manual are straightforward. In the SSO options you will be faced with the following options. Bold are the values that you should use in SURFconext:
Select your SSO options:
Automatically assign licenses
“Off” (default) set to “On”
Most defaults are good for use with SURFconext. The default Authentication Request Signin Algorithm is set to SHA1. Change this to SHA256. Not doing so will create an unclear error when login on. The option to Automatically assign licenses needs to be set to 'On'.
The next step in the manual depicts the configuration of the LinkeIn Learning metadata in SURFconext. When you connect to the service through SURFconext, SURFconext acts as an Identity Provider. For your institution SURFconext is a Service Provider. This is something which you have already configured, since you make use of SURFconext. With the information shown in the manual here, you need to have access to the Service Provider dashboard to upload metadata of the LinkedIn instance in the SP Dashboard. This is the preferred way. Alternatively you can ask us to upload the instance in SURFconext. You can do so by sending us the metadata file. Download the metadata as shown and send this to email@example.com.
Access to attributes was initially limited to the mandatory attribute mail. However, LinkedIn indicated that they also need to receive first givenName (first name) and sn (surname). Configure this in the dashboard accordingly.
This chapter points how to configure SURFconext as the Identity Provider to talk with LinkedIn's platform. We have two environments to connect with. The Public SAML metadata or the 'Entity Descriptor' of the SURFconext IdP proxy for the test environment differs from the production environment. The following applies:
Download the xml of your preference and upload it as depicted in the manual. Take note that if your LinkedIn instance is connected to the 'Test Environment' you can not and will not be connected to both identity providers on the production environment and the test environment. The user profiles from IdP's on the test environment are fictional or unverified. Real users, with their profiles can only connect to your service through the production environment of SURFconext. Once verified that you are connected to the production environment you must use the xml of the production environment as mentioned above.
If uploading the XML fails, use the following values to enter them manually:
To upload the SURFconext metadata by URL, make use of the following URL's of test or production:
Using a link has a big advantage since it will be fetched multiple times a day. Changes in the SURFconext metadata will be processed automatically as long as we don't change the metadata-URL.
At the time of writing LinkedIn Learning does not support the SURFconext federation but as an alternative you can select the edGAIN option since SURFconext is published in eduGAIN.
The following chapters in the manual can be used to enable the connection, configure custom attributes, etc. For this manual we will only say that you need to enable Single Sign-On to make LinkedIn Learning work with SURFconext. Send a connection request to firstname.lastname@example.org and supply us with a name we can refer to when we send the invite to the SURFconext-responsible contacts at you institution. This is probably you.
This part outlines some experiences instituions had with the admin centre of LinkeIn Learning.
The Admin Center enables you to set up two SSO connections. For example, a production and an acceptance instance. However, LinkedIn does not really have an acceptance environment and they share the same (user) data. We believe this is not really a way to test your connection because of privacy concerns. Consider this when making this instance. Once you have set up a second SSO connection, the option to add a new one disappears. You first have to delete an existing one if you want to add another one.
If you want to access the Admin Center as an administrator, you can't do so directly. You first have to log in and then switch to Admin Center. Furthermore, an administrator can register an account on LinkedIn that gets admin rights for configuring the SSO connection. Remember to logon using those credentials and do not use the SSO-option when you make changes to the LinkedIn Learning environment. Contact LinkedIn if you are locked out of the admin environment. They can also assist you in creating an admin account using SSO.
When migrating from Lynda.com to LinkedIn, LinkedIn migrates all users with an institution email address of the organization being migrated. These include users who are no longer registered at the organization or employees who are no longer working for the organization. For these, too, an e-mail is sent to the institution's e-mail address with instructions for the migration. This is especially a problem if the e-mail address of the departed has been reused for a new employee or student. He or she is then instructed on how to migrate the data of the former user of the e-mail address.