Standardmäßig werden innerhalb der audit log files viele interessante Informationen mitgeloggt.
Wie Sie z.B. die Anzahl an Logins und weiterer Parameter ihres IdP 2.x auslesen und ins Monitoring aufnehmen können entnehmen Sie folgender Seite.

idp audit log

Um das verwendete Analyse-Tool auch für den neuen IdP 3.x verwenden zu können müssen Sie jedoch zwei kleine Anpassungen vornehmen.

Zum einen müssen Sie das Log-Format anpassen. Hier fehlt ein abschließendes „|“ am Ende der Zeile.

conf/audit.xml

<!-- ... -->
 
    <util:map id="shibboleth.AuditFormattingMap">
        <entry key="Shibboleth-Audit" value="%T|%b|%I|%SP|%P|%IDP|%bb|%III|%u|%ac|%attr|%n|%i|" />
    </util:map>
 
<!-- ... -->

Der zweite Punkt wäre die Anpassung des eigentlichen Analyse-Tools. Hier ersetzen wir den Filter für einen Profil-Typ.

bin/analyseLog.py

<!-- ... -->
 
    if msgProfile.lower().endswith("/sso/browser"):
        db['logins'] += 1
 
<!-- ... -->

Hat man ein Monitoring-System, so entsteht schnell der Wunsch die wichtigsten Informationen des Shibboleth IdP zu überwachen.
Um nicht Gefahr zu laufen, dass aus dem Web heruntergeladene Metadaten veralten und ungültig werden, so finden Sie hier ein wirklich sehr simples Shell-Skript was dies für Sie prüft.

Dieses Skript lässt sich z.B. via NRPE durch Nagios oder andere kompatible Monitoring-Systeme direkt auf dem Shibboleth IdP ausführen und warnt wenn die heruntergeladenen Dateien nicht existieren oder deren Zeitstempel zu weit in der Vergangenheit liegt.

check_metadata_time.txt (Nach dem Download einfach die Dateiendung auf '.sh' ändern.)

Wie bereits erwähnt handelt es sich hierbei um ein sehr einfaches Skript, welches eher als Anreiz für eigene Überlegungen dienen soll.
Gern kann dieses mit Parametern versehen werden, um dynamisch die zu prüfenden Metadaten-Dateien zu bestimmen oder die Schwellwerte für Warnungen anzupassen.

Um eine aussagefähige Antwort geben zu können, ob der Login am Shibboleth IdP möglich ist empfiehlt es sich nicht nur einzelne Bestandteile des IdP zu betrachten, sondern im Idealfall einen kompletten Login-Vorgang durch zu führen.
Erst dann kann man aus Sicht des Nutzers sagen ob der Dienst wie gewünscht funktioniert.

Dazu finden Sie folgendes in Python geschriebene Skript, welches sich anbietet in das eigene Monitoring-System aufgenommen zu werden. Dabei wird das Skript lokal auf dem IdP (z.B. via NRPE) ausgeführt.

check_shiblogin_v3.txt (Nach dem Download einfach die Dateiendung auf '.py' ändern.)

Damit das Skript mit der eigenen Infrastruktur funktioniert müssten ein paar kleinere Anpassungen vorgenommen werden.
Der Test-Nutzer samt Passwort, sowie der zum Login benötigte SP sollten zunächst im Skript benannt werden. Gern kann dies auch durch weitere Parameter beim Aufruf des Skriptes übergeben werden.

check_shiblogin_v3.py

<!-- ... -->
 
    sp_entityid = "https://my.own.sp/shibboleth"
    sp_target_url = "https://my.own.sp/Shibboleth.sso/Session"
    user = "myuser"
    password = "mypassword"
 
<!-- ... -->

Des weiteren ist es nötig, dass der IdP UnsolicitedSSO unterstützt.

Und zu guter Letzt muss eventuell neben Python noch ein zusätzliches Modul Namens 'python-pyOpenSSL' für OpenSSL installiert werden.

Im Anschluss kann das Skript in 3 verschiedenen Modi ausgeführt werden.
Defaultmäßig, ohne Angabe zusätzlicher Parameter, arbeitet dieses im NormalLoginMode. Daneben existieren der ShortLoginMode und der FullLoginMode.

    usage: check_shiblogin_v3.py [-h] [-s | -f]

    Script to check if shibboleth-login is working. Normal login attempt stops after attribute release.

    optional arguments:
        -h, --help   show this help message and exit
        -s, --short  short login attempt, which stops after entering credentials at idp-side (stops on attribute-release-page)
        -f, --full   full login attempt, which stops after visiting session-page at sp-side