(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.
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.
Sie erhalten von LinkedIn die Metadaten Ihres hochschulspezifischen Tenant SP. Gehen Sie wie folgt vor, um ihn einzubinden:
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
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:
<!-- 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:
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.