Navigate / search

Přihlašování a SSO v Sametime

Řešil jsem teď jeden problém v Sametime: instalace byla v pořádku, vše fungovalo dobře, jenom SSO (Single Sign-On) se chovalo záhadně. Mezi ST Proxy (na WAS) a ST Community (na Dominu) to fungovalo výborně, ale mezi ST Proxy a ST Meeting (oba na WAS) ne. Člověk by řekl, že mezi oběma komponentami běžícími nad WAS poběží SSO bezproblémově a pokud budou nějaké potíže, tak při komunikaci mezi platformami.

Ono je to ale trochu jinak. Autentikaci pro ST Meeting dělá WAS, autentikaci pro ST Proxy dělá Domino. Tohle je nejdůležitější věta z tohoto článku, od které se vše odvíjí. Protože kdo dělá autentikaci, ten také generuje SSO cookies.

Když jsme hledali příčinu chyby, zkoumali jsme také cookies v prohlížeči. A zjistili jsme, že ST Proxy generovala SSO cookie s názvem LtpaToken, zatímco ST Meeting generoval cookie s názvem LtpaToken2. Z toho je teda jasné, že žádné SSO opravdu proběhnout nemohlo, když se tokeny jmenují jinak. Otevřeli jsme tedy Domino Directory a znovu překontrolovali SSO dokument. A zde byl kámen úrazu: při instalaci nového Sametime 8.5 se neudělal nový SSO dokument v Dominu, ale použil se již existující (kvůli iNotes).

Takže jsme se rozhodnuli udělat v Dominu nový, separátní SSO dokument, jenom pro potřeby Sametime — postup je na konci. A pozor, i zde je nutno dávat pozor na to, jak nastavíte generování SSO cookies. V Sametime 8.5 se používá WAS 7 a ta již defautně generuje pouze LtpaToken2, který je bezpečnější. Pokud chcete generovat i LtpaToken, musíte ve WAS zapnout Interoperability mód. Stejně se to dá nastavit i na Dominu, tam volíte, jestli se má generovat nový, starý nebo oba tokeny. A aby SSO fungovalo, musí být obě platformy nastaveny na stejnou hodnotu. Tedy buď obě pouze LtpaToken2 (tedy vypnutá Interoperability ve WAS) nebo obě povoleny oba tokeny.

Poznámka: Experimentálně jsem si potvrdil, že když negenrují obě platformy stejné tokeny, tak SSO funguje „z menšího do většího“. Když například nastavím Domino, že generuje (a tady i akceptuje) pouze LTPA2 a WAS generuje LTPA1 i LTPA2, tak SSO fungovalo ve směru z Domina do WAS. Naopak ne. Je to proto, že WAS rozuměla LTPA2, ale Domino nerozumělo LTPA1.

Po té, co jsme tedy udělali nový SSO dokument v Dominu, který generuje pouze LTPA2 a ve WAS vypnuli Interoperabilitu, vše zrestartovali, tak SSO začalo fungovat.

 

Samostatný SSO dokument pro Sametime

Domino pro své potřeby (např. iNotes) používá LTPA token, který se konfiguruje v dokumentu s názvem LtpaToken. Je to jeho defaultní hodnota a název se nemá měnit. Když potřebujete udělat nový SSO dokument a naimportovat do něj klíče z WAS, udělejte si nový SSO dokument a nazvěte jej třeba LtpaTokenST. (Poznámka: toto je pouze název dokumentu v names.nsf, není to název cookie, kterou dostane prohlížeč.) V něm nastavte, že platí pouze do Domino server, na kterém běží ST Coomunity server.

Teď už jenom zbývá někde v Sametime nastavit, že si nemá sahat pro defaultní dokument, ale pro dokument s novým názvem. Dělá se to přes sametime.ini (je v programovém adresáři Domina). Do sekce AuthToken přídáme tento řádek:

[AuthToken]
ST_TOKEN_TYPE=LtpaTokenST

Zrestartujeme Domino a je hotovo.

Leave a comment

name*

email* (not published)

website

This site uses Akismet to reduce spam. Learn how your comment data is processed.