How-To: Shibboleth „LocalDynamic“

06.01.2021 | Administrator

Aufgrund unserer technischen Expertise rund um E-Learning, beleuchten wir immer wieder einzelne technische Aspekte für interessierte Entwickler. Dieser Artikel behandelt die Übertragung einer Shibboleth Konfiguration von dem MetadataProvider Typ = "XML" zu "LocalDynamic".

Überblick

Die Shibboleth SP Konfiguration mit Standard XML Metadata Provider und vollständigen eduGain Metadaten benötigt in Abhängigkeit von der zur Verfügung stehenden Infrastruktur relativ viel Zeit beim Starten. Die Initialisierung kann mehrere Minuten dauern. Die Nutzung von "LocalDynamic" kann diese Zeit stark reduzieren.

Standardmäßig wird httpd bei CentOS nicht gestartet, bevor der Deamon shibd initialisiert ist. Auch wenn dies anders konfiguriert werden kann, dauert der Startup einige Zeit, weshalb wir nach einem Weg gesucht haben, diesen Prozess zu beschleunigen. In der Shibboleth-Dokumentation haben wir die Methode "LocalDynamic" gefunden, unglücklicherweise aber keine zusätzliche Information, wie diese zu verwenden  und konfigurieren ist.

In diesem Dokument beschreiben wir einen Weg, wie "LocalDynamic" anstelle des "XML" Metadata Provider verwendet werden kann.

XML Metadata Provider

In den meisten Konfigurations-How-Tos finden wir Beschreibungen zum Metadata Provider wie folgt (es kann auch mehr als 1 Element sein).

<MetadataProvider type="XML" url="<uri_to_metadata>"

   backingFilePath="<local_cache_file>" reloadInterval="3600"

   backgroundInitialize="true" ignoreTransport="true" >

   <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>

   <MetadataFilter type="Signature" certificate=”<path_to_certificate>"/>

</MetadataProvider>  

Diesem Tag folgen AttributeExtractor, AttributeResolver und AttributeFilter

Der MetadataProvider Typ "XML" holt sich die Daten von der angegebenen Url, prüft die Signatur, speichert die Daten intern und aktualisiert diese in einem vorgegebenen Intervall.

Unglücklicherweise muss dies beim Startup durchgeführt werden. Bei einem großen eduGain benötigt dies Zeit.

Wir ändern diese Konfiguration zu einer einfachen Zeile

<MetadataProvider type="LocalDynamic" sourceDirectory="/var/cache/shibboleth/ed"/>

Die Daten werden jetzt von dem lokalen Verzeichnis "/var/cache/shibboleth/ed” gelesen. Der Startup ist jetzt extrem schnell (Der Neustart des Service shibd benötigt bei uns jetzt weniger als eine Sekunde auf unserer virtuellen Maschine), aber: das Verzeichnis muss initialisiert und regelmäßig aktualisiert werden. Im folgenden beschreiben wir, wie dies gemacht werden kann.

Transport

Noch eine kurze Anmerkung: Wir kümmern uns nicht selbst um die Übertragung und das Herunterladen der Metadaten aus verschiedenen Gründen.

  • Aus Sicherheitsgründen ist es nicht empfohlen.
  • Es würde mehr Zeit in Anspruch nehmen, das lokale Verzeichnis zu füllen und optional ein Discofeed JSON zu erstellen.

So reservieren wir uns eine Maschine in unserem Netzwerk mit dem herkömmlichen MetadataProvider Typ "XML", und ziehen uns von dort Kopien. So kann die Maschine mit dem MetadataProvider Typ "XML" jede sein. Die lokalen Kopien können über das Attribut "backingFilePath" gefunden werden.

Es sind nur 2 Schritte von Nöten:

MetadataProvider XML -> LocalDynamic

Gemäß der Dokumentation Inhalte des Quellen-Verzeichnisses sind viele Dateien, die alle einen eindeutigen IdP EntityDescriptor besitzen. Der Dateiname ist der sha Hashwert der IdP entityId.

Den Hash generieren wir in bash:

echo -n "<idp_entityId>" | openssl sha1

oder in java:

MessageDigest md = MessageDigest.getInstance("SHA-1");

String hash = new String(md.digest("<idp_entityId>"));

Folglich schrieben wir ein einfaches Programm, das die großen MetadataProvider xml Dateien analysiert, den IdP EntityDescriptor herauszieht and die Dateien in dem LocalDynamic Verzeichnis generiert.

Wichtig: Dateinamen sind <hash>.xml (Der Suffix .xml darf nicht vergessen werden)

Das kann zusätzlich optimiert werden, in dem nur geänderte IdP EntityDescriptors geschrieben werden, jede Datei sollte wie folgt aussehen (Beispiel-Datei für TUM München):

Dateiname: b71c9974637b9c39e1bb57c784dfe100b5036408.xml:

<?xml version="1.0" encoding="UTF-8"?>

    <Extensions>

       […]

DiscoFeed

Nur notwendig, wenn du shibboleth-ds nutzt.

Im selben Prozess, wenn wir die Dateien des LocalDynamic Verzeichnis erstellen, schreiben wir auch eine vollständige json discofeed.json Datei, abhängig vom lokalen Setup. Wir legen die Datei /etc/shibbolethds/ab.

Folgende Änderungen nehmen wir vor:

In /etc/shibboleth-ds/idpselect_config.js ändern wir 

this.dataSource = './discofeed.json';

und fügen ein Alias /shibboleth-ds/discofeed.json in /etc/shibboleth-ds/shibboleth-ds.conf ein.

Die Struktur von discofeed.json ist einfach: Ein Array von

{

  "entityID" : "<entityId>",

  "DisplayNames" : [ {

    "value" : "<name1>",

    "lang" : "en"

}],

  "Descriptions" : [ {

    "value" : ">desciption1>",

    "lang" : "en"

  }],

  "Logos" : [ {

    "value" : "<logo url or also base64 data>",

    "width" : "<width>",

    "height" : "<height>"

 } ]

}

entityID + ist notwendig + mindestens ein DisplayName!

Mehrere DisplayNames für mehrere Sprachen sind optional, ebenso sind Beschreibungen und Logos optional!

Diese Informationen aus dem EntityDescriptor zu extrahieren ist sehr einfach.

Zum Leben erwecken

Ergänzt werden sollte dies durch Fehlerprüfung und Monitoring des Prozesses, um diese Architektur in Produktion zu nutzen. Monitoring ist essentiell für Shibboleth, du willst nicht in einem endlosen Ladeprozess der Metadaten enden. Daher stelle sicher, dass du die Fehlermeldungen des Shibboleth-Dienstes auf den Maschinen mit herkömmlichem MetadataProvider Typ "XML" und des Programms zur Generierung der Dateien im "LocalDynamic" Verzeichnis und der Datei DiscoFeed.json überwachst.

Wir finden folgende Zeilen in shibd.log:

2021-01-06 14:05:59 INFO OpenSAML.MetadataProvider.Dynamic [1] [default]: resolving metadata for (<entityId>)

2021-01-06 14:05:59 INFO OpenSAML.MetadataProvider.Dynamic [1] [default]: caching resolved metadata for ((<entityId>))

2021-01-06 14:05:59 INFO OpenSAML.MetadataProvider.Dynamic [1] [default]: next refresh of metadata for ((<entityId>)) no sooner than 28800 seconds

Um Testumgebungen zu konfigurieren ist der Typ "LocalDynamic" sehr angenehm. Der Start des Dienstes shibd ist rasend schnell und Änderungen können schnell getestet werden, selbst wenn Metadaten der Produktivumgebung genutzt werden.

Interested in the app? Let us know, it’s written in Java, we configured it in crontab hourly, can think of putting it into open source…

Interessiert an dem Programm? Lass es uns wissen. Es ist in Java geschrieben und wir haben es im crontab für einen stündlichen Lauf konfiguriert. Wir denken darüber nach, es als Open Source zur Verfügung zu stellen.