LinkedIn Learning

(zur Übersicht Attributfreigaben)

Etliche Hochschulen haben aus Datenschutzgründen bei LinkedIn Learning erreicht, dass nur die persistentId übermittelt wird und dass die Nutzer*innen nach dem Login weder dazu aufgefordert werden, Namen und Mailadresse anzugeben, noch den Account mit einem LinkedIn-Account zu verknüpfen. LinkedIn Learning unterstützt dies. Für die Nutzer*innen bedeutet ein pseudonymes Login jedoch deutliche Einschränkungen, denn der SP kann dann keine personalisierten Leistungsnachweise ausgeben. Standardmäßig ist dies möglich, dazu werden dann Namen und E-Mailadressen übertragen. Welchen Weg Sie beschreiten, wird von Einsatzszenarien des SP in der Lehre und/oder von Datenschutzvorgaben abhängen.

Um Ihren LinkedIn-SP zu konfigurieren, benötigen Sie den xml-Metadatensatz, den Sie von LinkedIn Learning erhalten haben.

1. Melden Sie sich mit dem Administrationsaccount an und gehen Sie in die globalen Einstellungen:
2. Klappen Sie die erweiterten Single Sign-On-Einstellungen aus:
3. Klicken Sie auf „Oder klicken Sie hier, um einzelne Felder aus dem Formular zu laden oder zu kopieren“:
4. Fügen Sie die EntityID (in das Feld „Instanz-ID“), das ACS-Bindung und das Zertifikat aus dem Metadatensatz ein:

Da LinkedIn Learning nicht an der DFN-AAI teilnimmt, müssen Sie Ihre IdP-Metadaten dort manuell in ein Webformular einpflegen. Diese Informationen sind dann statisch, das bedeutet, dass sie relevante Änderungen in den IdP-Metadaten (z.B. Zertifikatswechsel) dort auch von Hand nachpflegen müssen.

1. Holen Sie sich die Metadaten Ihres Identity Providers aus der Metadatenverwaltung, wie auf der Troubleshooting-Seite beschrieben. Verwenden Sie nicht die Datei idp-metadata.xml von Ihrem IdP - sie ist i.d.R. nicht auf dem aktuellen Stand.
2. Einige haben die Erfahrung gemacht, dass der Upload in dem Webinterface bei LinkedIn Learning nicht korrekt funktioniert. Sie können die Metadaten dort jedoch manuell einpflegen. („Möchten Sie die Informationen manuell eingeben? Hier klicken“)
3. So fügen Sie Ihre IdP-Metadaten hinzu:

Sie erhalten von LinkedIn die Metadaten Ihres hochschulspezifischen Tenant SP. Gehen Sie wie folgt vor, um ihn einzubinden:

1. Legen Sie in der Metadatenverwaltung einen neuen lokalen SP an: Wählen Sie in der Übersicht der Entitäten unter Service Provider den Knopf „Eine Entität aus vorhandenen Metadaten erzeugen“. Kopieren Sie den Inhalt der xml-Datei von Cisco in das Feld und laden Sie die Daten hoch.
2. Editieren Sie für die fehlenden Felder den SP-Metadatensatz wie folgt:
   • Displayname (deutsch und englisch): LinkedIn Learning
   • Beschreibung (deutsch und englisch): LinkedIn Learning (oder Sie denken sich etwas Ausführlicheres aus)
   • Information URL (deutsch und englisch): https://www.linkedin.com/learning/
   • Privacy Statement URL (deutsch und englisch): https://www.linkedin.com/legal/privacy-policy
   • Helpdesk (erg. Angaben zu Kontakte - Support): Die Helpdesk-Adresse Ihrer Heimateinrichtung
   • Kontakte: Hier geben Sie die üblichen Adressen Ihrer Heimateinrichtung ein.
   • NameID Formate: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
3. Im Abschnitt „Föderationen“ nehmen Sie den SP in Ihre lokalen Metadaten auf.
4. Nach der nächsten Aktualisierung der Metadaten steht Ihnen der Tenant SP zur Verfügung. Warten Sie mindestens 60 Minuten, bevor Sie testen.

Die LinkedIn-SPs sind nicht in der Lage, verschlüsselte SAML-Assertions zu verarbeiten. Sie können das wie folgt für diesen einen SP auf optional setzen. Dies und die Freischaltung der persistentId bewerkstelligen Sie mit folgenden Einträgen in der relying-party.xml:

./conf/relying-party.xml

    <!-- Dies kommt in den oberen Teil der Datei -->
    <!-- Für LinkedIn Tenant SP -->
    <bean id="linkedInOrgRegex"
        class="java.util.regex.Pattern" factory-method="compile"
        c:_0="^https://www\.linkedin\.com/learning/" />
 
    <bean id="linkedInOrgRegexPredicate"
        class="com.google.common.base.Predicates" factory-method="contains"
        c:_0-ref="linkedInOrgRegex" />
 
    <bean id="custom.RelyingPartyCondition"
        class="net.shibboleth.idp.profile.logic.RelyingPartyIdPredicate"
        c:_0-ref="linkedInOrgRegexPredicate" />
 
    <!-- Dies kommt unten zu den Relying Party Overrides -->
    <!-- Für LinkedIn Tenant SP -->
    <bean id="shibboleth.CustomRelyingParty" parent="RelyingParty">
        <property name="activationCondition"
        ref="custom.RelyingPartyCondition" />
        <property name="profileConfigurations">
            <list>
                <bean parent="SAML2.SSO"
                p:postAuthenticationFlows="#{ {'terms-of-use', 'attribute-release'} }"
                p:nameIDFormatPrecedence="#{ {'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'} }"
                p:encryptionOptional="true" />
                <ref bean="SAML2.Logout" />
            </list>
        </property>
    </bean>

Wenn Sie sich gegen die Anmeldung mit einer E-Mailadresse entschieden haben, können Sie Ihren Nutzer*innen einen Aktivierungslink zur Verfügung stellen, über den sie zum IdP kommen. Achtung: Dieser Link ist offenbar nicht statisch, sondern er ändert sich bei Konfigurationsänderungen! Sie könnten eine Weiterleitung von https://ihre-hochschule.de/LinkedInLearning auf den jeweiligen Aktivierungslink erstellen, so dass die Nutzer*innen davon nichts mitbekommen. So finden Sie den Aktivierungslink:

1. Melden Sie sich mit dem Administrator-Account an.
2. Gehen Sie zur Administratorseite.
3. Klicken Sie in der Menüleiste „Personen“ an, im Untermenü wählen Sie „Nutzer“ aus.
4. Klicken sie auf „Aktivierungslink erhalten“:
5. Der Aktivierungslink für Ihre Einrichtung wird Ihnen jetzt gezeigt:

Wenn Sie die Standardkonfiguration von LinkedIn Learning einbauen, dann müssen Sie in deren Konfigurationsformular das Mapping der Attribute vornehmen, wie im folgenden Screenshot zu sehen ist: Im linken Feld „Map to SSO“ geben Sie den Namen der SSO-Verbindung ein, den Sie oben gewählt haben (hier im Beispiel: „Shibboleth“).

Als Attributnamen geben Sie nicht den „friendly name“ an, sondern die standardisierte URN, so , wie sie für das jeweilige Attribut in conf/attribute-resolver.xml steht.

Der Zertifikatswechsel in der Metadatenverwaltung wird genau so durchgeführt wie bei anderen SPs auch, d.h. Sie lassen beide Zertifikate, das alte und das neue, vorübergehend parallel in den Metadaten stehen.

Die Fehlermeldung

Error Code: SSO_LOGIN_JIT_PROVISIONING_LICENSE_CREATION_FAILED

besagt, dass die Lizenzen, die Ihre Heimateinrichtung beim Anbieter erworben hat, aufgebraucht sind.