SAML vs. OAuth2

Security-all

Ez itt a kerdes.
Melyiket es miert szeressem jobban a masiknal?

Egyaltalan egy felhasznalo (sysadmin) szempontjabol mi a kulonbseg?
(egyelore zold vagyok a temaban)

10x

  • 2561 megtekintés

Azert, mert a ket protokollnak kicsit eltero a tamogatottsagi szintje. A legtobb 3rdparty cucc OAuth2-vel megy, SAML-lel nem, vagy nehezkes a provider adatait megkapni, mert "hivatalosan" nem tamogatjak az ilyen integraciot, hiaba tudna egyebkent a szoftver mindkettot terminalni.

Ezert kerdeztem, mert ha pl. GitHub-bal, Travissal, Dropboxszal, vagy FB-vel akarsz integralodni, akkor mindenkeppen OAuth, mert altalaban a kliens- es a szerver implementacioja ugyanabban a modulban szokott lenni, ha mar ugyis kell, akkor felesleges amellett meg a SAML-lel is szivni.
--
Blog | @hron84
Üzemeltető macik

Ha sajat, akkor erdemes elgondolkozni azon, hogy egyaltalan kell-e neked ez az egesz. Az Oauth-al az a baj ilyen szempontbol, hogy a legtobb Oauth provider kulon rakerdez, hogy engedelyezed-e az alkalmazasnak, hogy hozzaferjen az adataidhoz. Corporate belso authhoz erdemes megnezni a CAS protokollt, SAML-ra epit, de joval egyszerubb hozza szoftvert irni.

Ha megfapadosabbat akarsz, irtam anno egy egyszeru SSO specifikaciot, de sajnos ido hianyaban soha nem jutottam el oda hogy implementaljam.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Azert kell, mert most szuksegunk van vmire, ami ilyesmit csinal meg. De ha mar lesz, akkor legyen szabvanyos, amibol az alkalmazasok a sajat infrastrukturankon kivul is tudnak profitalni, azaz hozzaadott erteket kepvisel.

Szoval marad az oauth2 vs. saml. De nem tudom, melyiket akarom. Ahogy nezegetem, mik a lehetosegeim szerver oldalon, leginkabb egyiket sem, mindegyiktol vakarozom, de ez sem opcio:D

En arra jutottam, hogy ha az a cel, hogy randomfejleszto tudja hasznalni, akkor Oauth. Ehhez ugyanis rengeteg kesz library van es sokkal tobb a knowhow a neten, mint a SAML-lal kapcsolatban. Pl. egy Symfonyban (mert PHP mindenki kedvenc takernyelve) bedobod a HWIOAuthBundle-t, beletolod az API kulcsokat es tudsz autentikalni 50 szolgaltatassal. Ezzel szemben en az AWS-en kivul meg nem lattam olyan szolgaltatast ahol SAML-t hasznalnanak a "nyilt weben", inkabb tenyleg a corporate szoftverek tudjak alapbol es a specifikacio sem a konnyu esti olvasmany, szoval PHP Istvan nem fogja neked erre epiteni a szoftveret. Meg az olyan relative corporate szoftverek is, mint a Confluence, csak OAuth-ul beszelnek, SAML-ul meg csak draga fizetos pluginnal.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

( janoszen v | 2015. 10. 19., h – 13:55 )

Ha jol ertettem anno amit olvastam, a SAML inkabb corporate autentikalasra valo (nem is nagyon gyartanak hozza nem-corporate jellegu klienseket), amig az Oauth inkabb arra valo, hogy boldog-boldogtalannak lehetove tedd, hogy a Te directoryddal belepjenek. SAML-ra jo pelda az Amazon AWS vs. Microsoft AD. Ennek megfeleloen a beallitas is meglehetosen kacifantos.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

En is ilyet olvastam, de ezzel egyutt sem kerek nekem a dolog.
Sehol nem latom leirva, hogy az egyik ne tudna azt, amit a masik...legalabbis a lenyegi dolgokban. Amit akarok, hogy legyen authentication meg authorization.

Most egyelore ott tartok, hogy tisztesseges, egyszeru, szerver oldali resze nincs egyiknek sem. Mindegyik olyan, hogy ossze kell takolni vhogy.

Egyelore a legbiztatobbnak a Gluu nevu projekt tunik, ami lenyegeben egy ernyo projekt kisebb-nagyobb modositasokkal a tobbinek.
Raadasul mintha mindket protokolt is tudna, de egy kicsit el vagyok veszve benne:D

A SAML-t az OpenSSO szinte biztos, hogy tudni fogja, meg egyebkent vannak fizetos providerek is, pl anno a Sun-nak is volt identity providere, talan azt meg futtatja az Oracle.

Egyebkent az SSO szivas mindenkeppen, csak a mennyiseget szabalyozhatod... :-) Kicsit olyan, mint a PKI.
--
Blog | @hron84
Üzemeltető macik

OK, de az OAuth2-re van szerver javaslatod?

SAML-ra van pl. a shibboleth, olyat legalabb lattam mar.
Amugy nem az OpenSSO az, ami a sun-e volt?;)
"OpenSSO was an open source access management and federation server platform (SSO acronym stands for Single Sign-On ).

Announced by Sun Microsystems [...]"

Szerintem önálló oauth2 szervert nem nagyon fogsz találni, legalábbis nem ingyenest. Mi pl. saját felületet készítettünk hozzá, ami ezt a libraryt használja: https://github.com/bshaffer/oauth2-server-php

SAML-ra amúgy vannak openam-nél egyszerűbb megoldások, nyilván nem is annyira profik, pl.: https://simplesamlphp.org/

( sj | 2015. 10. 19., h – 20:30 )

alaposan nezz a kormere a valasztott ouath2 implementacionak, mert a wikipedia szerint boven vannak flawed megoldasok is...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( bajnokk | 2015. 10. 20., k – 13:53 )

Én a nyílt forrású SAML implementációkat ismerem (Shibboleth, SimpleSAMLphp). Ezekhez sys-admin szempontból nem kell hozzányúlni, ha egyszer sikerült bekonfigurálni.

A hozzászólásokból sem világos számomra, hogy mire van szükséged. Ha csak intézményen belüli single sign-onra, akkor vannak ezeknél egyszerűbb megoldások is, pl. szerintem a DACS (http://dacs.dss.ca/) ilyen, bár sosem használtam.

A SAML rendszerek legnagyobb előnye, hogy támogatja a "szövetségi azonosítást" (Federated Identity Management), azaz különböző intézmények tartják karban a felhasználókat, akiknek az SP nyújt szolgáltatást. Ezek eléggé elterjedtek egyetemi környezetben, és Magyarországon is van ilyen, lásd http://www.eduid.hu . Ha esetleg egyetemekkel, akadémiai intézményekkel akarsz együttműködni, akkor ezt javaslom.

Az OAuth, esetleg az OpenID Connect a SAML-nál egyszerűbb, és a nagy social platformok által támogatott, de ezekkel nincs gyakorlati tapasztalatom. Az OAuthot könnyű triviálisan feltörhetőre csinálni (erről hallottam egy előadást, de a részleteket már elfelejtettem), szóval észnél kell lenni, ha értékes dolgokat akarsz megvédeni vele.

> A hozzászólásokból sem világos számomra, hogy mire van szükséged. Ha csak intézményen belüli single sign-onra, akkor vannak ezeknél egyszerűbb megoldások is, pl. szerintem a DACS (http://dacs.dss.ca/) ilyen, bár sosem használtam.

Van ezerfele, de en olyan szeretnek, ami szabvanyos, idotallo es jo esellyel ismerik az alkalmazasok. Pl. ezt ismeri az owncloud? Mostegyik helyre konkretan ahhoz keresek megoldast.
Amugy nem intezmenyen belul. Persze nezopont kerdese. Az intezmeny az ugyfeleit authentikalja a stuff.

> akadémiai intézményekkel akarsz együttműködni, akkor ezt javaslom.

Nem akarok.

> Az OAuth, esetleg az OpenID Connect a SAML-nál egyszerűbb, és a nagy social platformok által támogatott, de ezekkel nincs gyakorlati tapasztalatom. Az OAuthot könnyű triviálisan feltörhetőre csinálni (erről hallottam egy előadást, de a részleteket már elfelejtettem), szóval észnél kell lenni, ha értékes dolgokat akarsz megvédeni vele.

Igen, errol olvastam en is.

Owncloud + SAML-ot csináltunk már. Volt olyan idő, amikor a meglevő plugint ellehetenítették és csak az enterprise változat SAML megoldása működött (azaz van hivatalos SAML támogatás is). Nem tudom, mi az aktuális helyzet, mi 8.0-val használjuk, van benne némi házi barkácsolás is, de ez talán nem volt szükségszerű.