Apache Syncope and Active Directory SSO: configurazione di OpenAM

Questo sarà il primo, di una serie di post, che avranno, come punto di arrivo, la realizzazione di un overlay di Syncope con la particolarità di essere in Single Sign On con un'istanza di Active Directory. Attraverso differenti passi, vedremo come arrivare ad avere un utente che, una volta autenticatosi su un PC windows con autenticazione a Dominio, potrà accedere sulla console di Syncope senza autenticarsi ulteriormente.

Environment

• Windows Server 2008 R2: acacia.fabioad.controller.tirasa.net
• AD domain: fabioad.controller.tirasa.net:389
• Apache Syncope (porta 9080) e Openam (porta 8080), deployati su due Tomcat differenti, sullo stessa macchina Debian: joda.tirasa.net

Obiettivo finale: Single Sign On da Active Directory ad Apache Syncope

• Autenticazione su Pc windows con un utente presente su Active Directory
• Visualizzare attraverso il browser la console di Syncope su http://joda.tirasa.net:9080/syncope-console
• Usare la console di Syncope con lo stesso utente autenticato su Windows senza un'ulteriore autenticazione

Obiettivo di questo post: configurazione di OpenAM

Pre-requisiti

• L'installazione di OpenAM è stata eseguita in modo corretto

Configurazione del modulo di autenticazione Windows Desktop SSO

Per raggiungere l'obiettivo finale si è deciso di utilizzare il modulo di autenticazione Windows Desktop SSO che ci permette, in modo trasparente, di ottenere il SSO tra AD e OpenAM. Per fare questo dobbiamo seguire i seguenti semplici passi.

1. Creare un utente su AD che "rappresenti" OpenAM: openam / password
2. Associargli un keytab da usare proprio su OpenAM con questo comando:
   ktpass /out joda.HTTP.keytab /mapuser openam /pass password /princ HTTP/joda.tirasa.net@FABIOAD.CONTROLLER.TIRASA.NET /ptype KRB5_NT_PRINCIPAL /Target FABIOAD.CONTROLLER.TIRASA.NET</span>
3. Copiare il keytab generato sul server Debian e configurare il modulo di autenticazione windows desktop sso, di seguito la mia configurazione creata con lo script ssoadm di OpenAM:
   ./ssoadm create-auth-instance -m AD -t AD -u amadmin -f pwdFile -e /
   ./ssoadm update-auth-instance -e / -m AD -u amadmin -f pwdFile -a "iplanet-am-auth-ldap-server=srv-dctest.adtest.lan:389" "iplanet-am-auth-ldap-base-dn=ou=domain,dc=adtest,dc=lan" "iplanet-am-auth-ldap-bind-dn=cn=administrator,cn=users,dc=fabioad,dc=controller,dc=tirasa,dc=net" "iplanet-am-auth-ldap-bind-passwd=password" "iplanet-am-auth-ldap-user-naming-attribute=sAMAccountName" "iplanet-am-auth-ldap-user-search-attributes=sAMAccountName" "iplanet-am-auth-ldap-user-search-attributes=userprincipalname" "iplanet-am-auth-ldap-return-user-dn=false"
   Oppure tramite console:
   Service Principal: HTTP/joda.tirasa.net@FABIOAD.CONTROLLER.TIRASA.NET
   Keytab File Name: /home/tirasa/keytab/joda.HTTP.keytab
   Kerberos Realm: FABIOAD.CONTROLLER.TIRASA.NET
   Kerberos Server Name: acacia.fabioad.controller.tirasa.net
   Return Principal with Domain Name: false
   Authentication Level: 0
4. Configurare il browser per il passaggio del token
   1. Accedere su Internet Options > Advanced > Security.
   2. Selezionare Integrated Windows Authentication option. (default)
   3. Clicca sul tab Security >Local Internet.
   4. Seleziona Custom Level nel pannello User, seleziona Automatic Logon Only in Intranet Zone option.
   5. Vai su Sites e seleziona tutte le options.
   6. Clicca su Advanced e aggiungi l'url joda.tirasa.net

Configurazione del Data Store di Active Directory

Dopo aver configurato il modulo di autenticazione per il SSO, bisogna configurare un nuovo Data Store su OpenAM in modo tale che dopo l'autenticazione, OpenAM sia in grado di rilevare il profilo dell'utente autenticato e non dia errore.
Questa è la mia configurazione, creata sempre attraverso l'uso dello script ssoadm:
./ssoadm create-datastore -e / -m AD -t LDAPv3ForAD -u amAdmin -f pwdFile -a "sunIdRepoAttributeMapping=cn=cn" "sunIdRepoAttributeMapping=userPassword=unicodePwd" "sunIdRepoAttributeMapping=sn=sn" "sunIdRepoAttributeMapping=uid=sAMAccountName" "sun-idrepo-ldapv3-config-ldap-server=fabioad.controller.tirasa.net:389" "sun-idrepo-ldapv3-config-authid=FABIOAD\Administrator" "sun-idrepo-ldapv3-config-authpw=password" "sun-idrepo-ldapv3-config-organization_name=cn=users,dc=fabioad,dc=controller,dc=tirasa,dc=net" "sun-idrepo-ldapv3-config-users-search-attribute=userPrincipalName" "sun-idrepo-ldapv3-config-createuser-attr-mapping=cn=cn" "sun-idrepo-ldapv3-config-createuser-attr-mapping=userPassword=unicodePwd" "sun-idrepo-ldapv3-config-createuser-attr-mapping=sn=sn" "sun-idrepo-ldapv3-config-createuser-attr-mapping=uid=sAMAccountName" "sun-idrepo-ldapv3-config-groups-search-attribute=sAMAccountName" "sun-idrepo-ldapv3-config-group-container-name=sAMAccountName" "sun-idrepo-ldapv3-config-group-container-value=" "sun-idrepo-ldapv3-config-people-container-name=sAMAccountName" "sun-idrepo-ldapv3-config-people-container-value=" "sun-idrepo-ldapv3-config-auth-naming-attr=sAMAccountName" "sun-idrepo-ldapv3-config-psearchbase=cn=users,dc=fabioad,dc=controller,dc=tirasa,dc=net"

Punti di interesse

Questa sicuramente è la fase meno interessante dal punto di vista tecnico. Sicuramente però il comando per l'associazione dell'utente al keytab è da tenere a mente in quanto, anche spulciando per la rete, questa dai noi attuata, risulta la soluzione più comoda e immediata. Rispetto alle altre trovate in altri blog o wiki. A questo proposito bisogna sottolineare che il nome fabioad.controller.tirasa.net all'interno del comando è relativo al nome della macchina in questione, praticamente l'hostname.

1 VOTIYes, Excellent!