Qualche volta Milano stupisce con qualche chicca d’antologia, oggi è toccato alla Varadero sidecar!

Come risollevare le sorti di una giornata di merda:

1. effettuare upgrade del proprio Ubiquiti Unifi controller che gira su un minuscolo Raspberry PI
2. ripristinare il backup della vecchia istanza di Unifi controller che gira sempre sul minuscolo Raspberry PI
3. deployare l’ultima versione di firmware sul proprio access point Ubiquiti AP LR
4. abilitare il tanto agognato protocollo SNMP
5. osservare che snmpwalk si spazzola i mib SNMP del proprio access point

Dunque vediamo…

1, 2, 3 –> DONE

4, 5 –> DONE

Basta così poco per farmi felice… :)

Lavorando con WebSEAL su un virtualhost junction mi è recentemente capitato di avere qualche disguido, nello specifico si è trattato di un virtualhost junction ad accesso riservato dove l’applicazione di backend in single sign-on catturava lo UID dell’utente (passato tramite variabile IV_USER) e lo utilizzava per attività di vario genere.
Abbiamo osservato una anomalia quando l’utente effettuava la login inserendo degli spazi in coda allo username (es “utente   ” anzichè “utente”), mentre WebSEAL lo autenticava correttamente l’applicazione di backend generava una serie di eccezioni che si manifestavano con un loop continuo di richieste http.

Verificando l’anomalia ho provato a riprodurla su un ambiente di sviluppo, ricreando il virtualhost junction nello stesso modo e associando all’oggetto l’acl per forzare la login (all_auth).

In questo caso ho utilizzato come risorsa di backend un banalissimo webserver php dove ho piazzata una semplicissima pagina (headers.php) che estraesse le variabili passate da WebSEAL (-c all), in particolare la variabile IV_USER:

<?php
$user = $_SERVER['HTTP_IV_USER'];
$groups = $_SERVER['HTTP_IV_GROUPS'];
$userl = $_SERVER['HTTP_IV_USERL'];
$creds = $_SERVER['HTTP_IV_CREDS'];
?>
<ul>
<li>iv_user: <?php echo $user ?></li>
<li>iv_groups: <?php echo $groups ?></li>
<li>iv_user_l: <?php echo $userl ?></li>
<li>iv_creds: <?php echo $creds ?></li>
</ul>

Il risultato di una login con spazi in coda allo username è stato il seguente.

GOTCHA!
Verificando sull’infocenter IBM ho trovato una technote che descrive proprio il problema in questione (anche se riferito ad un problema sul componente di integrazione SSO ETAI, che nel caso specifico non stavo utilizzando).
La soluzione consiste nel creare il virtualhost junction configurando gli headers con encoding “UTF8 Binary” anzichè “UTF8 URI Encoded” (parametro -e utf8_bin)

Una volta effettuata questa piccola modifica il risultato è stato il seguente e il problema si è risolto.

Una delle operazioni fondamentali del setup di una nuova istanza WebSEAL consiste nel fare in modo che il prodotto protegga determinati oggetti mediante autenticazione (di vario genere, basic, form authentication o altro) e permetta l’accesso anonimo verso altri.

Apparentemente l’operazione è banale, si creano entità nello spazio oggetti di WebSEAL e si applicano differenti ACL in base alle proprie necessità.
Ad esempio si possono creare due ACL, una (all_view) per l’accesso anonimo e una (all_auth) per l’accesso autenticato (senza distinzioni di gruppi o utenti), ciascuna con i propri parametri di accesso.

Si sfoglia lo spazio oggetti di WebSEAL mediante il comando “object list” e una volta ottenuto il percorso esatto dell’oggetto desiderato (per esempio una transparent junction /wps che espone un portale WebSphere Portal) occorre collegare l’ACL all’oggetto mediante il comando “acl attach <object-name> <acl-name>”.

Con il comando “object show” si può verificare il dettaglio dell’oggetto e le acl ad esso associate (Attached ACL) oppure ereditare da un oggetto padre (Effective ACL).

Durante un nuovo setup però può capitare che l’effetto di questa operazione non sia quello voluto, insomma che le ACL non funzionino a dovere oppure che l’associazione tra l’oggetto e l’ACL non sia efficace.
In realtà questa eventualità è piuttosto remota (almeno io non ho mai osservato un comportamento simile sebbene siano anni che mi trovo a lavorare con questo prodotto IBM), è molto più probabile che vi siate dimenticati di settare un parametro fondamentale nel file di configurazione di WebSEAL.

Nel dettaglio potete osservare che la junction dell’esempio /wps ha valorizzato il parametro “Basic authentication mode” con “supply” (comando “server task <SERVER NAME> show <JUNCTION NAME>”)

Guardacaso nel file di configurazione di WebSEAL (percorso di default su GNU/Linux: /opt/pdweb/etc/webseald-<SERVER NAME>.conf ), sotto stanza “server” è presente il parametro “allow-unauth-ba-supply” che di default è valorizzato in modo tale da non permettere l’accesso anonimo a junction con flag BA attivo.

Una volta modificato il parametro inserendo come valore “yes” e riavviato WebSEAL (pdweb restart) la junction ad accesso anonimo risulterà rispondere correttamente.

Scrivo questo post a futura memoria, per evitare che tragedie simili si ripetano in futuro…

Centro di Milano (zona S. Ambrogio), locale che dall’esterno sembra una comune rosticceria/salumeria, menù:

• un piatto (nemmeno abbondante) di tortellini di carne al ragù
• un piattino di contorno a base di zucchine saltate in padella e patate al forno
• 1/2 litro di acqua naturale
• caffè

• un piatto misero di tortellini (4) con ripieno di ricotta e spinaci
• un piattino di contorno a base di zucchine saltate in padella e patate al forno
• 1/2 litro di acqua naturale + un bicchiere di vino rosso
• caffè

A me tremano ancora le gengive dalla mazzata nei denti che abbiamo preso, giudicate voi dagli scontrini…