Konfigurace OpenAM nad 389 Directory Server

V rámci řešení single sign on pro jednoho z našich zákazníků jsme napojovali do infrastruktury opensourcový access manager OpenAM. Jako databáze pro něj byl vybrán LDAP server 389DS. Článek stručně shrnuje odlišnosti a zádrhele, které bylo zapotřebí při konfiguraci vyřešit.

OpenAM

OpenAM, dříve Sun OpenSSO, je open source nástroj běžící v aplikačním serveru. Pro svou funkci potřebuje dvě databáze – databázi uživatelů a databázi pro vlastní konfiguraci. Obě databáze budeme chtít dostat na 389DS.

OpenAM lze postavit i nad jeho vlastní datové úložiště, ale podporuje i tato externí:

• SunDS
• OpenDS
• OpenDJ
• MS Active Directory
• IBM Tivoli

Podle dokumentace je možné tento access manager provozovat nad jakýmkoliv LDAPv3-compliant adresářovým serverem, realita je ale trochu zajímavější. Hlavní problém totiž způsobují schémata v LDAP serverech, která bohužel nemusí vždy splňovat nároky OpenAM. Při samotné konfiguraci access manageru to nemusí ještě vadit, ale důsledky mohou být celkem zajímavé.

389 Directory Server

Někdy také Fedora Directory Server, opensourcová varianta Red Hat Directory Serveru. Konfiguraci acces manageru nám velice usnadnilo i to, že 389DS je příbuzný oficiálně podporovaného SunDS, a tedy se dá počítat s tím, že rozdíly schémat mezi nimi nejsou moc velké.

Konfigurace

Po počátečním nainstalování 389DS jsme vytvořili dva kořenové suffixy, každý s vlastní fyzickou databází:

o=bcv
o=openam

kořen o=netscaperoot slouží k uchování nastavení samotného LDAPu. Tyto databáze budou sloužit jednak k uchovávání uživatelů se SSO přístupem (suffix bcv) a k uchování nastavení access manageru (suffix openam). Nyní můžeme nakonfigurovat OpenAM.

Při prvním spuštění se zobrazí standardní dialog, který provede uživatele nastavením administrátorského účtu, url agenta a datových úložišť. Trik pro konfiguraci úložišť je velice jednoduchý – OpenAM konfigurujeme, jako kdyby jeho backendem měl být SunDS. Díky příbuznosti se OpenAM zkonfiguruje správně a téměř vše bude funkční. Takto nakonfigurujeme obě datová úložiště. Protože OpenAM se vždy ptá na kořen, kde jsou data uložená, můžeme ho velice jednoduše nasměrovat na naše oddělené databáze.

 

V posledním kroku počátečního nastavení si OpenAM registruje své služby do LDAPu. Tato operace proběhne bez problémů. Nyní by se nám mohlo zdát, že je vše připraveno, bohužel ale záhy zjistíme, že nám přes administrační rozhraní OpenAM nejdou zakládat uživatelé. Příčinou je chybějící objectclass iPlanetPreferences, která není ve schématu 389DS definovaná.

Odstranění problému je velice jednoduché – modifikujeme schéma tak, aby danou třídu obsahovalo. Její vlastnosti jsou následující:

objectclass: iPlanetPreferences
předek: top
OID: žádné
required atributy: žádné
allowed atributy: preferredLanguage, preferredLocale, preferredTimeZone

 

Nyní lze uživatele zakládat a access manager funguje bez problémů. Naštěstí není nutné si se schématem více hrát.

A kdo si chce hrát…

Při řešení tohoto problému jsem po krátkém hledání narazil na tento zápisek, který v podstatě shrnuje, jaké objectclass a atributy je ve schématu adresářového serveru nutno mít, aby OpenAM fungovalo. V podstatě se jedná o obecný návod pro ty LDAPv3 servery, které mají výrazně odlišná schémata.

objectclassy:
inetadmin
inetorgperson
inetuser
iplanet-am-managed-person
iplanet-am-user-service
iplanet-am-session-service
iPlanetPreferences
organizationalperson
person
sunAMAuthAccountLockout 
top

atributy:
cn
dn 
employeeNumber
givenName
inetUserStatus
iplanet-am-static-group-dn
iplanet-am-user-account-life
iplanet-am-user-alias-list
iplanet-am-user-auth-config
iplanet-am-user-failure-url
iplanet-am-user-success-url
iplanet-am-user-login-status
mail
objectClass
postalAddress
preferredLocale
sn
sunAMAuthInvalidAttemptsData
sunIdentityMSISDNNumber
telephoneNumber
uid
userPassword

Samozřejmě tyto objectclass nejsou tak jednoduché, jako byla iPlanetPreferences, ale k podrobnostem snadno dopomůže vyhledávač.

Závěr – k čemu to vlastně bylo dobré

Ukázali jsme si, jak lze jednoduše nakonfigurovat access manager OpenAM, aby jako svoje datové úložiště použil “nepodporovaný” LDAP 389DS. Veškerá další kofigurace, která se v rámci access manageru provádí, už je běžnou rutinou. Vedlejším efektem je, že umíme portovat OpenAM na v podstatě jakýkoli LDAP backend.

V tomto okamžiku můžeme používat náš oblíbený 389DS jako autoritativní zdroj uživatelů pro SSO. Navíc adresářový server můžeme jednoduše napojit na CzechIdM, a tedy není problém tímto způsobem využít CzechIdM ke správě uživatelů v SSO infrastruktuře.

Pokud vás článek zaujal a chtěli byste se dozvědět více, neváhejte se mi ozvat na info@bcvsolutions.eu.

Další témata