[MEGOLDVA] OTRS SSO SAML2.0 shibboleth.

Hálózatok egyéb

Sziasztok!

Eléggé ritka vagy szerintem ritka problémába ütköztünk. Kérem aki tudna benne segíteni jelentkezzen.

Tömören van egy SAML 2.0 protokollon komminikáló, működő backend rendszer amivel a shibd látszólag képes kommunikálni.

A futtató OS Ubuntu 18.04, a tesztelésre használt OTRS verziója 6.0

../var/log/shibboleth/shibd.log
2019-04-16 16:36:42 INFO Shibboleth.Listener [46]: detected socket closure, shutting down worker thread
2019-04-16 16:36:42 INFO Shibboleth.Listener [47]: detected socket closure, shutting down worker thread
2019-04-16 16:36:42 INFO Shibboleth.Listener [45]: detected socket closure, shutting down worker thread
2019-04-16 16:41:39 INFO XMLTooling.StorageService : purged 149 expired record(s) from storage

../var/log/shibboleth/transaction.log
2019-04-16 15:14:50 INFO Shibboleth-TRANSACTION [4]: Cached the following attributes with session (ID: ) for (applicationId: default) {
2019-04-16 15:14:50 INFO Shibboleth-TRANSACTION [4]: }
2019-04-16 15:59:28 INFO Shibboleth-TRANSACTION [10]: New session (ID: ) with (applicationId: default) for principal from (IdP: none) at (ClientAddress: 163.242.213.49) with (NameIdentifier: none) using (Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID: )
2019-04-16 15:59:28 INFO Shibboleth-TRANSACTION [10]: Cached the following attributes with session (ID: ) for (applicationId: default) {
2019-04-16 15:59:28 INFO Shibboleth-TRANSACTION [10]: }

../var/log/shibboleth/shibd_warn.log
2019-04-16 15:52:41 WARN Shibboleth.AttributeExtractor.XML : attribute mappings are reloadable; be sure to restart web server when adding new attribute IDs
2019-04-16 15:56:41 WARN Shibboleth.AttributeExtractor.XML : attribute mappings are reloadable; be sure to restart web server when adding new attribute IDs

Mivel az otrs alapvetően default így a default Apache vhost-ban konfiguráltam.

/etc/apache2/sites-enabled/000-default.conf

AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
ShibUseHeaders On
ShibRequestSetting myid yx.cc.org

Ez alapján eljutok az SSO alapját adó auth oldalra, ott az AUTH végbemegy és redirect-el vissza de a redirect-et nem értem. Ott egyébként "too many redirect" hibát dobnak a böngészők.

A fő probléma, hogy sajnos nem tudom, hogy az OTRS mit vagy miért nem kap.

../opt/otrs/Kernel/Config.pm

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';

Alapján bekerül egy log sor:
Tue Apr 16 17:05:06 2019 error OTRS-CGI-32 Need User!

Auth módok egyike sem működött és nem reagált.
SAML2SP
SAML2 (ilyen modul nincs, error log is született rá)
shibboleth

Ha valaki már találkozott hasonlóval kérem jelentkezzen és ha tud segíteni akkor a hálánk nem fogja elkerülni.

Ha van olyan cég aki képes ebben segíteni akkor szintén nyugodtan jelentkezzen és segíthet hivatalos keretek közt.

Ha bármilyen egyéb konfig érdekes lenne, jelezze aki értheti és azonnal teszem.

Üdv,
Oli

  • 1915 megtekintés

( uid_21239 | 2019. 04. 16., k – 17:55 )

Valami erdekes a /var/log/shibboleth/apache2/native.log-ban?
ShibRequestSetting myid yx.cc.org <- Ez miert kell?

A $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth'; gyanusan nem jo, hiszen nem BasicAuth-ot akarsz.
De mivel OTRS-t nem lattam meg kozelrol, annak konfiguralasaban nem tudok segiteni. Ami az auth modot illeti, annak shibboleth-nek kellene lennie, ha shibboleth mogul akarjatok hasznalni.

Egy fontos dolgot tudnek kiemelni. A kliens app-nak tudnia kell, hogy a szamara szukseges mezoket (felhasznaloi nev, email cim, stb) milyen neven keresse a http request-ben. Mi gitlab-ot hasznalunk shibboleth mogul, annak a vonatkozo konfigja igy nez ki:

gitlab_rails['omniauth_providers'] = [
{
"name" => 'shibboleth',
"args" => {
"shib_session_id_field" => "HTTP_SHIB_SESSION_ID",
"shib_application_id_field" => "HTTP_SHIB_APPLICATION_ID",
"uid_field" => 'HTTP_XXXXXX_PERSON_COMMONNAME',
"name_field" => 'HTTP_XXXXX_PERSON_COMMONNAME',
"info_fields" => { "email" => 'HTTP_XXXXX_PERSON_EMAIL'}
}
}
]

Köszönöm. Megnézem.

Elvileg az otrs szerinti ldap alapon működő uid kerül átadásra az shibd-nek, de nem tudom, hogy igen-e de szerintem nem. A másik hogy nem tudom, hogy ez az otrs-hez hogy jut el, dokumentáció szerint elvileg httpbasicauth-al mivel az Apache shibd mód-ja dolgozza fel.

Sajnos túl sok a találgatás és feltételezés.

Tudsz linket kuldeni ahhoz a doksihoz?
Erosen ketlem, hogy basicauth-ot kellene hasznalni kliens oldalon. A basicauth nem mas, mint felhasznaloi nev + jelszo. A shibboleth SP, ami az apache alatt dolgozik nem tudja mi a jelszo. Az authentikacio az IDP-n tortenik, az csak egy tokent kuld vissza a SP-nek a felhasznaloi nevvel es email cimmel egyutt. Jelszot biztos, hogy nem, igy nem is lehetseges basicauth-tal belepni.

Az OTRS dokumentáció ennyit tartalmaz:

HTTPBasicAuth for Agents
...
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';

https://doc.otrs.com/doc/manual/admin/6.0/en/html/external-backends.html

A célrendszer alapvetően 7.0 és az SSO elegendő lenne az external oldalra, az agent vagyis a /otrs/index.pl esetében nem lényeges, oda inkább a 2FA kellene.

( Atis89 v | 2019. 04. 17., sze – 00:58 )

Létezik a customer user OTRS-ben, amivel be szeretnél lépni?
Az OTRS-ben tárolt login és az eppn megegyezik?

A kérdéses user biztosan létezett mert azzal LDAP-auth konfigurációval már beléptem.

A SAML válasz ennyi, de ebben én nem látok userID-t ami a mail cím lenne ami egy ldap/user attributum.

Elnézést, a probléma által érintett terület és téma túlnyomórészt ismeretlen számomra.

A külső auth oldal ennyit ad vissza a felületen:

"
Login successful, loading web site
If you are not automatically forwarded to the application, please click here.
"

Egy ilyen URL-t:

https://rs.TÖRÖLT.TÖRÖLT.com:9443/SSO/Login/win?LOCALE=en_US&origin=CES…ÖRÖLT_APP_ID&config=new&Design=default_design_intranet&GAREASONCODE=-1&autoLogin=true&GAURI=https%3A%2F%2Frs.TÖRÖLT.TÖRÖLT.com%2FGetAccess%2FSaml%2FIDP%2FSSO%2FRedirect%3FGAState%3DE81B2491FAA275544484184002768AC02EE6046F3&AUTHMETHOD=Windows

Amire ennyi a válasz:
ERR_TOO_MANY_REDIRECTS

és egy SAML message decoder ennyit fejt ki:

kép

nézzük már meg, hogy biztosan megkapjuk-e a szükséges paramétereket Shib-től.
Pl dobj fel egy fájlt ami kidumpolja a shib által átadott értékeket (akár egy egyszerűbb php-t is print_r($_SERVER);

Persze ha bátrabb vagy, akkor nyugodtan mehet az OTRS HTTPBasicAuth modulba is a logoltatás

Már igen, úgy tűnik, hogy igen és az LDAP-al használható usert is tartalmazza:

kép

Azt feltételezem, hogy ez alapján a user map menne:

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';
$Self->{'Customer::AuthModule::LDAP::Host'} = 'ldaps://TÖRÖLVE.TÖRÖLVE.TÖRÖLVE';
$Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=TÖRÖLVE,dc=TÖRÖLVE,dc=TÖRÖLVE';
$Self->{'Customer::AuthModule::LDAP::UID'} = 'mail';
$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'CN=TÖRÖLVE,OU=TÖRÖLVE,OU=TÖRÖLVE,OU=TÖRÖLVE,OU=TÖRÖLVE,DC=TÖRÖLVE,DC=TÖRÖLVE,DC=TÖRÖLVE';
$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'TÖRÖLVE';
$Self->{'Customer::AuthModule::LDAP::Params'} = {
port => 636,
timeout => 120,
async => 0,
version => 3,
};

és valószínűleg itt tévedek valahol, mert csak ennyi lesz a logba:

Thu Apr 18 06:59:48 2019 error OTRS-CGI-32 Need User!

Igyekszem domp-olni a forgalmat de nem tudom, hogy tegyem.

( freeoli v | 2019. 04. 17., sze – 11:49 )

Az access log ilyenből kap azonnal pár oldalnyit:


TÖRÖLT.TÖRÖLT.com:443 TÖRÖLT_IP_CÍM - - [17/Apr/2019:11:33:45 +0200] "GET /otrs/customer.pl?RelayState=ss%3Amem%3A0a991268187b27e8b5cd8e5ba44a8a846dfdc0e2521fadb0c3f2293883ed165d&SAMLart=AAQAAJfJP8TPVjhxqRL8OaAQWl5e27X0AAAAADZDpeXFoBmwQm3SB0%2FePLQ%3D HTTP/1.1" 302 1832 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36"

( freeoli v | 2019. 04. 17., sze – 13:59 )

ACS / ARS URLs Binding-ot Artifact Bindinga-al használtam rossz URL-t, ez van lejjebb, de a cél nem a *.pl hanem post binding és HOST/Shibboleth.sso/SAML2/POST.

Az eredményét még nem tudok mert az SSO szerű remote auth site konfigja nem nálam van és még nem futott le a módosítás.

( freeoli v | 2019. 04. 18., cs – 12:29 )

Ismét megpróbálkoztam a google használatával és sikerült ennek segítségével nyomokra bukkanni.

D.A. részére köszönettel tartozom. A prezentáció, leírás szerint próbáltunk eljárni és az alábbi modullal kiegészíteni az alkalmazást:

https://github.com/diego-araujo/OTRS-HTTPBasicAuthShib

Config.pm


$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuthShib';
$Self->{'AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuthShib';
$Self->{'Customer::AuthModule::HTTPBasicAuthShib::UID'} = 'mail';

/opt/otrs/Kernel/System/CustomerAuth/HTTPBasicAuthShib.pm


package Kernel::System::CustomerAuth::HTTPBasicAuthShib;

/etc/shibboleth/attribute-map.xml


/etc/apache2/sites-enabled/otrs.conf

/etc/apache2/sites-enabled/000-default.conf


--- vagy /
...
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
ShibUseHeaders On
ShibRequestSetting TÖRÖLVE TÖRÖLVE.TÖRÖLVE.com
...

( freeoli v | 2019. 04. 23., k – 14:28 )

A /var/log/shibboleth/shibd.log

2019-04-23 13:59:54 INFO Shibboleth.SessionCache [1]: new session created: ID (_8045d50ad99ae67cc529d4f64920f2ea) IdP (yy.törölt.domain.com) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (törölt_IP)
2019-04-23 14:01:07 INFO Shibboleth.SessionCache [5]: new session created: ID (_b58500b476e951ba5ee7e6e1593dc84d) IdP (yy.törölt.domain.com)
Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (törölt_IP)

1. Oldal megnyittása
2. Forvard az SSO*-t biztosító auth oldalra
3. Post binding-al a session? elvileg létrejön.

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';

4. Itt megáll a folyamat és au OTRS-hez már nem jut el a? Mi is? User neve kellene ami egy visszaadott attributum és benne is van a képek közt ami kellene.

Innen nyrt konfigokkal is próbálkoztam de semmire nem jutottam.

https://id.usp.br/saml/apache-saml/

Nem tudom, hogy az OTRS milyen módon kapná vagy dolgozná fel. Valakinek dereng valami?

A log ennyit ír összesen:

TIME PRIORITY FACILITY MESSAGE
Tue Apr 23 14:22:55 2019 error OTRS-CGI-32 Need User!
Tue Apr 23 14:15:14 2019 error OTRS-CGI-32 Need User!

( bajnokk | 2019. 04. 23., k – 15:20 )

Az OTRS integrációjához nem értek, de két hibalehetőség valamelyikét valószínűsítem:

1. A visszairányítás után a requestet nem védi a Shibboleth. Ez lehet sok minden miatt: http/https különbség, host név alias (nem mindig mindegy), path/symlink, redirect. Emiatt a Shibboleth az adott requesthez nem teszi az attribútumokat a session-be, ezért nem tudja az OTRS kiolvasni.

2. Az adat ott van, csak másik változóban. Írasd ki, esetleg nézd meg, hogy mit ad vissza a /Shibboleth.sso/Session path-on.

Nagyon köszönöm. Megpróbálok válaszolni.

A /var/log/shibboleth/transaction.log-ban kért adat megtalálható:

2019-04-23 15:54:09 INFO Shibboleth-TRANSACTION [1]: New session (ID: _e9d22a0375f4e0ab338af40718631133) with (applicationId: default) for principal from (IdP: rs.entitlement.siemens.com) at (ClientAddress: TÖRÖLT IP ) with (NameIdentifier: törölt e-mail cím) using (Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID: ADCA6E4181E6D90564872D0CB0449449E63011B0C)
2019-04-23 15:54:09 INFO Shibboleth-TRANSACTION [1]: Cached the following attributes with session (ID: _e9d22a0375f4e0ab338af40718631133) for (applicationId: default) {
2019-04-23 15:54:09 INFO Shibboleth-TRANSACTION [1]: HTTP_MAIL (1 values)
2019-04-23 15:54:09 INFO Shibboleth-TRANSACTION [1]: }

Erre:
https://TÖRÖLT.TÖRÖLT.com/Shibboleth.sso/_e9d22a0375f4e0ab338af40718631…

Ennyit kapok:

shibsp::ConfigurationException
The system encountered an error at Tue Apr 23 15:57:07 2019
To report this problem, please contact the site administrator at root@localhost.
Please include the following message in any email:
shibsp::ConfigurationException at (https://TÖRÖLT.TÖRÖLT.com/Shibboleth.sso/Sesson/_e9d22a0375f4e0ab338af4…)
Shibboleth handler invoked at an unconfigured location.

És erre is:
/var/log/shibboleth/shibd.log
2019-04-23 15:56:14 INFO Shibboleth.SessionCache [1]: new session created: ID (_7590ca1f2a774c687582044d2b145bc8) IdP (TÖRÖLT.TÖRÖLT.TÖRÖLT.com) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (TÖRÖLT)

A https://TÖRÖLT.TÖRÖLT.com/Shibboleth.sso/Session lenne érdekes, feltéve, hogy a TÖRÖLT.TÖRÖLT.com -on fut az oldalad.

Illetve tegyél az otrs mappájába egy phpinfo()-t generáló oldalt, és abban nézd meg a session változókat, van-e benne HTTP_MAIL? Ha van, akkor az otrs-nek működnie kell. Ha van, de máshogy hívják (tipikusan: REDIRECT_HTTP_MAIL), akkor a mod_rewrite elrontja a dolgokat. Ha nincs, akkor ott nem véd a Shibboleth: https://wiki.shibboleth.net/confluence/display/SP3/WontProtect

Sikerült, értem már.

Miscellaneous
Session Expiration (barring inactivity): 474 minute(s)
Client Address: Törölt IP címem
SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Identity Provider: xy.Törölt.Törölt.com --- ez a SAML2.0 provider.
Authentication Time: 2019-04-24T06:52:10Z
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:WindowsProtectedTransport
Authentication Context Decl: (none)

Attributes
HTTP_MAIL: 1 value(s) --- ez az e-mail címem ami alapján az LDAP auth működik.

A PHP infot má rakom is.

A protect így néz ki és a provider által adott leírás szerint van beállítva.

/etc/apache2/sites-enabled/000-default.conf

AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-session
ShibUseHeaders On
ShibRequestSetting törölve_ID törölve.törölve.com --- ez a provider oldalán azonosítja a rendszert ami alapján odaát lehet meghatározni a küldendő user attributumokat de nem mindet.

/etc/apache2/sites-enabled/otrs.conf

....

AuthType HTTPBasicAuthShib
ShibRequestSetting törölve_ID törölve.törölve.com --- ez a provider oldalán azonosítja a rendszert
require valid-user
ShibRequireSession On

Korábban ezt írtad:

$Self->{'Customer::AuthModule::HTTPBasicAuthShib::UID'} = 'mail';

Viszont te a HTTP_MAIL-be viszed valahogy az email címet. (Talán az attribute-map.xml-ben.)

Továbbá, fogalmam sincs, hogy ez a sor mit csinál:

AuthType HTTPBasicAuthShib

Alapvetően azt javaslom, hogy az apache konfigból szedj ki minden shibbolethes kézi konfigurációt, használj .htaccess-t, és abba tedd bele, hogy

AuthType Shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting törölve_ID törölve.törölve.com
Require shib-session
ShibUseHeaders On

Ekkor egyetlen helyen van a konfiguráció, és - amennyiben a .htaccess file értelmeződik, azaz AllowOverride +AuthConfig engedélyezett -, az biztosan érvényre jut.

Köszönöm a nyomokat és a nyomok megmutatását.

Ez:
AuthType HTTPBasicAuthShib

Innen volt:
https://github.com/diego-araujo/OTRS-HTTPBasicAuthShib

Amint ezt alkalmaztam, módosítva a javasolt ponttal:

https://github.com/meisterheister/otrs-SAML-Auth

Vagyis mit is használjon user ID-nek:

...
my $User = $ENV{HTTP_MAIL};
...

Így betöltve az auth modult:

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuthMellon';

Azonnal működni is kezdett. Vagyis megy az SSO.

AZ összegző bejegyzést igyekszem megírni és közzétenni, hogy másnak is segítségére legyen. Igaz, itt csak az OTRS és SHBD oldala lesz meg, a SAML provider oldaláról csak mint customer találkozunk vele, viszont az átadott adatokat mi konfiguráljuk.