Letztens musste ich SimpleSAMLphp als SP/IdP für mein lokales SSO Entwicklungssystem aufsetzen. Allerdings wollte der SSO Vorgang nicht recht funktionieren.
Nach einigem Stochern in den Logs bin ich auf folgendes gestoßen:

flo@acer ~ $ tail -f /var/log/apache2/error.log
...
[Sun Nov 15 15:41:52 2009] [error] [client 127.0.0.1] ALERT - configured GET variable value length limit exceeded - dropped variable 'SAMLRequest' (attacker '127.0.0.1', file '/var/www/simplesaml/saml2/idp/SSOService.php'), referer: http://sp-ssphp.localhost/simplesaml/saml2/sp/idpdisco.php?entityID=http%3A%2F%2Fsp-ssphp.localhost%2Fsimplesaml%2Fsaml2%2Fsp%2Fmetadata.php&return=http%3A%2F%2Fsp-ssphp.localhost%2Fsimplesaml%2Fsaml2%2Fsp%2FinitSSO.php%3FRelayState%3Dhttp%253A%252F%252Fsp-ssphp.localhost%252Fsimplesaml%252Fexample-simple%252Fsaml2-example.php&returnIDParam=idpentityid

Die Logmeldung weißt auf einen Verstoß gegen die Suhosin Richtlinen für die maximale Parameterelänge hin. Da die SAML2 Nachricht “vorneherum” via GET Variable übertragen wird ergibt sich ein recht ansehnliche Parameterlänge, welche von Suhosin als Angriff gewertet und geblockt wird.

Um das Problem zu beheben muss einfach die maximale Parameterlänge in der /etc/php5/conf.d/suhosin.ini erhöht werden. Eine Erhöhung von 512 auf 1024 hat in meinem Fall ausgereicht:

flo@acer ~ $ cat /etc/php5/conf.d/suhosin.ini
...
;suhosin.get.max_value_length = 512
suhosin.get.max_value_length = 1024
...

Viel Spass!

Nachtrag
Folgendes muss auch noch angepasst werden:

flo@acer ~ $ cat /etc/php5/conf.d/suhosin.ini
...
;suhosin.cookie.max_name_length = 64
suhosin.cookie.max_name_length = 128
...

Standardmäßig benutzt Ubuntu den Nano Editor. Dieser ist für eingefleischte Vim User aber natürlich keine geeignete Alternative.


Zum Glück lässt sich der System Editor leicht wechseln:

flo@acer ~ $ sudo update-alternatives --config editor
Es gibt 4 Auswahlmöglichkeiten für die Alternative editor (welche /usr/bin/editor bereitstellen).

  Auswahl      Pfad                Priorität Status
------------------------------------------------------------
* 0            /bin/nano            40        Auto-Modus
  1            /bin/ed             -100       manueller Modus
  2            /bin/nano            40        manueller Modus
  3            /usr/bin/vim.basic   30        manueller Modus
  4            /usr/bin/vim.tiny    10        manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein: 3
update-alternatives: Verwende /usr/bin/vim.basic, um /usr/bin/editor (editor) in manueller Modus bereitzustellen.

Anmerkung dazu:
Der “echte” Vim verbirgt sich unter der Option 3 /usr/bin/vim.basic und muss ggf. erst durch ein

flo@acer ~ $ sudo apt-get install vim

installiert werden, da Ubuntu nur den abgespeckten vim-tiny mibringt.

Als ich mich unter Karmic daran gemacht habe den Shibboleth2 Service Provider einzurichten war ich zunächst mal positiv überrascht.
Es gibt nämlich tatsächlich ein Ubuntu Package für den aktuellen Shibboleth 2.1, das sich fix und einfach installieren lässt.
Unter Gentoo/Suse musste ich jedesmal von Source kompilieren um an die aktuelle Version zu kommen. Von daher schonmal ein thumbs-up für Ubuntu karmic.
Also gleich ans Werk…

flo@acer ~ $ sudo apt-get install libapache2-mod-shib2

Problem
Nach dem Installieren und Konfigurieren klappte es allerdings nicht so recht mit dem Starten.
Ein Startversuch mittels

flo@acer ~ $ sudo service shibd start

wurde mit folgenden Logeinträgen quittiert

flo@acer ~ $ tail -f /var/log/shibboleth/shibd.log
...
2009-11-15 14:09:58 INFO Shibboleth.Listener : listener service starting
2009-11-15 14:09:58 ERROR Shibboleth.Listener : socket call resulted in error (2): no message
2009-11-15 14:09:58 CRIT Shibboleth.Listener : failed to bind to socket.

Lösung
Eine kurze Google Recherche förderte zutage, dass Shibboleth versucht seinen socket unter /var/run/shibboeth zu erstellen. Allerdings existiert das Verzeichnis nicht, was zu dem genannten Fehler führt. Da /var/run von Zeit zu Zeit automatisch wieder gelöscht wird genügt es nicht das Verzeichnis einfach zu erstellen. Stattdessen kann man das Initscript des Shibboleth Daemons unter /etc/init.d/shibd anpassen, so dass das fehlende Verzeichnis bei jedem Start angelegt wird, sofern es noch nicht existiert.
Und das geht ganz einfach so:

flo@acer ~ $ sudo sed -i '50 i \nif [ ! -e /var/run/shibboleth ]; then\n\tmkdir /var/run/shibboleth\nfi\n' /etc/init.d/shibd

Der obige Code fügt an Zeile 50 des Initscriptes eine entsprechende Abfrage ein und erstellt das fehlende Verzeichnis bei Bedarf.

Quellen

• http://blog.stastnarodina.com/honza-en/spot/shibboleth-ubuntu/

As always: Hope that helps!

• http://www.visualcomplexity.com/vc/
• http://www.userfriendly.org/
• http://www.ted.com/index.php

Verweigert Thunderbird den Zugriff auf dein Googlemail Konto mit der Meldung “Web Login Required” so bedeutet das, dass jemand zu oft versucht hat sich mit einem falschen Kennwort in dein Konto einzuloggen.
Um das Knacken des Kennwortes durch BruteForce durchprobieren zu verhindern, sperrt Google nach einigen Fehlversuchen den Zugang.
Um das Konto wieder zu aktivieren muss man sich dann z.B. unter https://www.google.com/accounts/UnlockCaptcha mit den korrekten Daten anmelden.
Im Unterschied zum normalen Login besitzt diese Seite ein grafisches Captcha, um den automatisierten Zugriff zu erschweren.
Nach dem Entsperren sollte die normale Anmeldung zu dem Konto – auch via Thunderbird – wieder funktionieren.

Seid ich in letzter Zeit wieder vermehrt mit PHP arbeite und daraus auch ein Projekt mit grafischer Oberfläche entstanden ist (siehe RRZE Icon Inspector) bin ich relativ begeistert von PHP-GTK.

Beim Installieren des aktuellen Eclipse unter Ubuntu 9.10 (karmic) bin ich auf einen sehr nervigen Bug gestoßen.


Das Problem
Mit karmic das neue Gnome 2.28.1 und damit GTK+ 2.18 eingführt wurde, welches seit neuestem ein verändertes Windowmanagement – sogenannte “Client-Side Windows” – benutzt. Da Eclipse dies offenbar nicht ordentlich unterstützt sind einige Schaltflächen nicht klickbar bzw. bleiben bei einem Klick “versenkt” ohne jedoch auszulösen. Außerdem Ist die Liste installierbarer Plugins (New Software) unsichtbar.

Die Lösung
Die Lösung ist die Umgebungsvariable GDK_NATIVE_WINDOWS mit der man GTK+ dazu bewegen kann wieder das alte Fenstermodell zu benutzen.
Startet man Eclipse wie folgt funktioniert es wieder einwandfrei.

flo@acer ~ $ GDK_NATIVE_WINDOWS=1 /opt/eclipse/eclipse

Das Ganze lässt sich dann auf Wunsch noch in ein kleines Shellscript verpacken.

Quellen

• http://forum.ubuntuusers.de/topic/ubuntu-9-10-und-eclipse-3-5/
• http://library.gnome.org/devel/gtk/2.18/gtk-migrating-ClientSideWindows.html