Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Modrá je dobrá
zelená je lepší

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub Web [ŽP: neomezená] (kategorie Programování) moderuje Kdokoliv.
Archiv
Domovská stránka aktualizována 28.7.2019 17:46
  
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: rtsbrra
[ 4074 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
bredy 2.8.2010 08:36  7372
knedleještě tam dam zdrojáky v PHP. Teď jsem měl bohužel rodinné problémy, máme rekonstrukci baráku, takže času moc není, ale slibuju. Jinak samotné ověření na straně serveru je jednoduché, a pro lopuchy by dokonce stačilo, aby to vydávalo kladné potvrzení, pokud je uživatel prostě přihlášen na lopuch. Vyžaduje to ale přístup do domény Lopuch.cz a to vyžaduje zásah spolupráci lopuchu.
knedle knedle online - Krabice živých 2.8.2010 08:20  7371
Bredyeasylogin - dokazes to prokopnout se na lopuch? vyuzil bych (stejne jako huh) pro lopusacke substranky (u me krabka)
el_diablo El_Diablo Veškerá nepodstatná elektronická zařízen - mimo provoz, včetně kontroly pravopisu. 31.7.2010 16:01  7370
Sedm vyvolených dostalo klíče, kterými lze nahodit internet. Mezi nimi i Čech
bredy 26.7.2010 20:54  7369
RiderMě te zajímá technická část projektu, kdy mi jde jen o prostor na serverech a o CNAME v DNS (pro seznamácke domény).
rider Rider - Asociace chovatelů antropomorfních koní 26.7.2010 20:44  7368
Což o to, produkťáka... Ale RP a hlavně uživatele...
bredy 26.7.2010 20:09  7367
RiderLojza si nemusí dělat účet u IdP. Má už účet na Seznamu, to mu stačí :-) U Seznamu má účet polovina národa. Mě bude stačit přesvědčit našeho produkťáka, aby mi tu službu povolili v rámci volného času naprogramovat. Tedy, ještě to nemám schválený, uvidíme.

www.easylogin.net - není to hotový, ale přihlašování funguje. Zbývá mi napsat ještě popisy a zveřejnit zdrojáky. Pokud to budete testovat, tak se po úpravě profilu nezapomeňte odhlásit, protože v rámci session ověřuje heslo jen jednou a pak už vydává ověření bez hesla. V sekci úprava profilu je odhlašovací odkaz.
rider Rider - Asociace chovatelů antropomorfních koní 26.7.2010 18:19  7366
Hlavní smysl běžné autentifikace je ověření, že ten Lojza co přišel dneska je ten samý Lojza, který tu byl minulý týden. Ty ve skutečnosti nepotřebuješ vedět kdo to je. Jen potřebuješ autentifikovat konkrétního uživatele. Lojza svěřil své přihlašování nějakému IdP, kterému věří a přenáší tedy zodpovědnost za svou bezpečnost na někoho třetího, který jej umí zabezpečit lépe, než nějaký, skoro nedůvěryhodný SP uživatelským jménem a heslem.

Ano, máš pravdu, že pro identifikaci a autentizaci mi stačí tohle. Jenomže Lojza si účet u IdP neudělá, protože nemá proč. Proč by zatahoval do věci další subjekt, který tam není potřeba? O tom je ten třetí zákon.

Prostředníka má smysl do toho zatahovat v okamžiku, kdy mi dá nějaké ověřené claimy, čímž zabrání např. vtipálkovi vyplnit registrační formulář e-shopu nesprávnými údaji, protože jeho adresa bude claimem, který IdP ověří.

Ale nehádej se tady se mnou a nepřesvědčuj mne. Naprogramuj to a přesvědč uživatele, aby to používali. Já ti jenom říkám, proč to nebude fungovat.

bredy 26.7.2010 16:16  7365
RiderZbytečně nafukuješ problém:

Nemohu si ale být jist, jaké claimy mi budou schopni dát a jak budou zajištěné.

Tohle ale v zásadě nepotřebuješ. Hlavní smysl běžné autentifikace je ověření, že ten Lojza co přišel dneska je ten samý Lojza, který tu byl minulý týden. Ty ve skutečnosti nepotřebuješ vedět kdo to je. Jen potřebuješ autentifikovat konkrétního uživatele. Lojza svěřil své přihlašování nějakému IdP, kterému věří a přenáší tedy zodpovědnost za svou bezpečnost na někoho třetího, který jej umí zabezpečit lépe, než nějaký, skoro nedůvěryhodný SP uživatelským jménem a heslem.

Ta je ovšem bohatě vyvážená komplikovanějším procesem přihlášení a registrace a nutností aby se uživatel *někde* nějak registroval a ideově souhlasil s tím, že tenhle účet třetí strany použije

Z mého pohledu je komplikovanější registrovat se v každém e-shopu, který navštívím jednou, maximálně dvakrát. Nehledě na to, že poskytuju osobní údaje, aniž bych měl jistotu, že ty osobní údaje nezneužije někdo třetí. Teď mi nejde o vlastní SP, ale vlivem okolností (jedná se o e-shop) použiji slabé heslo, které někdo uhodně a získá tak přístup k informacím, které by neměl vědět.

Druhá možnost je, že potřebuji mít uživatele nějak "předověřené", potřebuju, aby mi IdP dal nějaké konkrétní claimy a nějak se za ně zaručil

Nepotřebuješ. Smyslem autentifikace je ověřit uživatele podle jeho ID. Nepotřebuješ znát jeho adresu a bydliště. Nezajímá tě, zda ty informace jsou důkladně ověřené. Ty víš, že lojza přišel z počitače jidra.oprsalek.cz, ze tam má nějakého IdP a jaké má to IdP zabezpečení tě nezajímá. Pokud si Jindra a Lojza lezou do zelí tě jako SP nezajímá. Ty poskytuješ služby uživatelům na IdP jidra.oprsalek.cz.

Modelový příklad: provozuju e-shop a hodilo by se mi vědět, že uživatelem zadané jméno a adresa je skutečné, takže budu mít větší jistotu, že to není vtipálek

Proč chceš od systému něco, co ti na současném systému nic nezaručí? Jak zabráníš vtipálkovi vyplnit registrační formulář v e-shopu neplatnými údaji? Srovnávej srovnatelné. Přihlašování přes prostředníka řeší jiný problém, než ověření reálných osobních údajů uživatele. Ani to kolikrát není žádoucí!

Proto je ostatně SAML tak složitý - předpokládá se, že požadovaného efektu dosáhnu nikoliv programováním, ale parametrizací, nějakým hotovým řešením

Samozřejmě, autokololetadloponorka bude vždycky velice drahá a náročná na provoz a na řízení.

bude Aukro skutečně chtít být IdP?
Ale IdP a SP si nemusí lést konkurenčně do zelí. Třeba Aukro má plné právo nebýt IdP. Ale také to může být zajímavý způsob, jak při přihlašování k jinému aukčnímu serveru umístit do dialogu přihlašování display reklamu na aukce Aukra. Mimochodem, do minulého pátku jsem netušil, jak tahle display reklama řepí třeba na Seznamu.

Samozřejmě, že jak IdP tak SP mohou své protějšký omezit, IdP pomocí returnUrl a SP pomocí domény.
huh huh 26.7.2010 16:15  7364
Ty žiješ v moc enterprise světe :-) Já myslím, že praxe ukazuje, že vedle enterprise řešení má často šanci se uchytit i něco malého šikovného, viz třeba xml-rpc vs. soap, relax ng vs. xml schemata atd.

Já nepotřebuju integrovat moduly IS, ale jako obyčejná brambora bych klidně uvítal něco, abych třeba pro přihlášení přiblblé mailové konference se nemusel registrovat a vymýšlet heslo.

Tj. chci třetí stranu, která si (třeba zasláním dopisu) ověří, že adresa je skutečně funkční.

To je sice hezký, já bych chtěl třeba zlatý hodinky :-), ale Bredyho systém nemusí řešit všechny problémy světa.
rider Rider - Asociace chovatelů antropomorfních koní 26.7.2010 15:57  7363
Facebook login je případ specifický ve dvou ohledech:

1. Drtivá většina webů, které používají Facebook login ho nepoužívá pro klasickou autentizaci, ale protože jsou s Facebookem relativně těsně propojeny a integrovány, bez něj by neměly moc smysl. Typický příklad: NetworkedBlogs

2. Řada webů (třeba i ty pornosity) ho používá kvůli dolování dat, dostanou se tak k relativně cenným údajům.

Facebook login, stejně jako Microsoft Passport zase trpí na centralizaci. Oba jsou proprietální systémy, které stojí a padají na ochotě těch subjektů je podporovat.

Jenomže to je v zásadě jakýkoliv systém s prostředníkem - třetí stranou. Možná ne proprietární, ale rozhodně závislý na ochotě IdP jimi být a zůstat. Jako relying party mám tedy na výběr ze dvou možností a obě jsou špatné.

Buďto budu akceptovat zcela jakéhokoliv IdP, čímž si zajistím nezávislost na konkrétním subjektu. Nemohu si ale být jist, jaké claimy mi budou schopni dát a jak budou zajištěné. Jedinou výhodou pak představuje, že si uživatel nemusí pamatovat další heslo. Ta je ovšem bohatě vyvážená komplikovanějším procesem přihlášení a registrace a nutností aby se uživatel *někde* nějak registroval a ideově souhlasil s tím, že tenhle účet třetí strany použije (idea, že si rozjede vlastního IdP je spíš teoretická). V takovém případě tedy třetí strana nemá fakticky smysl a porušuje třetí zákon.

Druhá možnost je, že potřebuji mít uživatele nějak "předověřené", potřebuju, aby mi IdP dal nějaké konkrétní claimy a nějak se za ně zaručil. V tom případě nicméně potřebuju jednoho nebo více konkrétních IdP, na nichž se tím stávám fakticky závislým (i když používám otevřenou technologii). Tady má ověřování třetí stranou smysl, ale přesto naráží na řadu netechnických problémů: Např. kde takového IdP vzít a nekrást? Zadarmo to asi dělat nebude a je ekonomicky rozumné mu za to platit? Pokud to bude IdP mít jako "přidruženou výrobu", hrozí konflikt zájmů. Pokud to bude dělat jako obživu, asi brzo zhyne.

Modelový příklad: provozuju e-shop a hodilo by se mi vědět, že uživatelem zadané jméno a adresa je skutečné, takže budu mít větší jistotu, že to není vtipálek, kterému pošlu dobírku, která se vrátí jako nedoručitelná a budu s tím mít akorát vydání. Tj. chci třetí stranu, která si (třeba zasláním dopisu) ověří, že adresa je skutečně funkční. Hodilo by se mi, kdybych mohl jako IdP použít třeba Aukro, které u svých uživatelů adresu korespondenčně ověřuje. Jenomže: bude Aukro skutečně chtít být IdP? Když tím bude pomáhat své konkurenci? Budu já chtít, aby Aukro vědělo, kdo jsou moji zákazníci? Budou se moji zákazníci chtít přihlašovat účtem třetí strany? Vyplatí se nějaké nezávislé třetí straně provozovat takovou službu?

Význam technologií, jako je SAML, je spíše v jiných oborech, v uzavřených nebo polouzavřených systémech. Např. abych já, jako ISV mohl dodat aplikaci, která snadno půjde zapojit do infrastruktury odběratele. Nebo pokud chci dělat nějakou federated identity, třeba umožnit do extranetu přístup partnerům a podobné věci. Proto je ostatně SAML tak složitý - předpokládá se, že požadovaného efektu dosáhnu nikoliv programováním, ale parametrizací, nějakým hotovým řešením. Že to bude problém "IT Pro" ne "Developer". Od toho tady jsou programy jako ADFS (Active Directory Federation Services od Microsoftu), již zmiňovaný Shibboleth (což je open source v rámci projektu Internet2), Athens (používaná v UK) nebo Tivoli (od IBM).

bredy 26.7.2010 10:04  7362
RiderŘekl bych, že jsi podlehl přání otce myšlenky. Zajímavý je, že podle tebe nemají takové systémy šanci na úspěch, ale že dost lidí bez problémů používá Facebook login (a viděl jsem to i na pornositech), to ti asi uniklo. Bohužel, Facebook login, stejně jako Microsoft Passport zase trpí na centralizaci. Oba jsou proprietální systémy, které stojí a padají na ochotě těch subjektů je podporovat.
rider Rider - Asociace chovatelů antropomorfních koní 26.7.2010 02:39  7361
Můj systém tento zákon neporušuje, protože systém je založen na přihlášené přes prostředníka.
Ano. A to je důvod, proč se nerozšíří a nebude úspěšný. A také proč se nerozšířil a není úspěšný a masově používaný žádný systém přihlašování přes prostředníka. I to OpenID je mezi slepými jednooký králem, dohromady to nikdo nepoužívá.
bredy 23.7.2010 22:27  7360
Zákony identityNašel jsem někde český překlad těch zákonů, což zlepší porozumění, a vychází mi toto: (zdroj: http://is.muni.cz/th/173294/fi_b/bc.pdf)

1. Systémy pro práci s identitami smějí předat informace o uživateli pouze s jeho souhlasem. Uživatel tedy musí vědět, jaké informace o něm systém uchovává, komu a v jakém rozsahu je předává. Zároveň s jejich předáním musí explicitně souhlasit, jinak k předání informací o uživateli nesmí dojít.

Splněno. Uživatel má plnou kontrolu nad svým profilem. IdP může pomoci uživateli vybrat, které informace poskytne SP.

2. Systém, který uchovává a spravuje co nejméně identifikačních údajů, je z dlouhodobého hlediska nejstabilnější. Se zvětšujícím se množstvím spravovaných informací rostou náklady na jejich zabezpečení a každý systém by tak měl pracovat pouze s informacemi, které nutně potřebuje.

Jestli to dobře chápu, jde o to, aby uživatel měl představu o tom, které informace bude služba ke své činnosti potřebovat. Pravda, že tento bod zatím nesplňuji, protože SP nemá momentálně způsob jak IdP sdělit rozsah požadovaných informací, tedy uživatel musí předpokládat, že SP bude vyžadovat všechny informace a tedy je na něm rozhodnout, které poskytne. Zároveň IdP nemá řečeno, které informace jsou povinné. Teoreticky tedy uživatel nemusí poskytnout žádné informace výjma ProfileID, který slouží ke spárování uživatelského profilu IdP s identitou na straně SP.

3. Systém musí být navržen tak, aby přístup k informacím měli povoleny pouze takové subjekty, kterých se dané informace bezprostředně týkají.

Můj systém tento zákon neporušuje, protože systém je založen na přihlášené přes prostředníka. Není tam jediný subjekt, který by do systému neměl mít přístup. Nic o vedlejším kanále. Nic o tom, že by si SP a IdP neměly vyměňovat informace sloužící k ověření vlastní seance.

4. Systém musí umět podporovat tzv. ”všesměrové“ identity pro veřejné subjekty a ”jednosměrné“ identity pro soukromé subjekty. Za všesměrové identity považujeme takové subjekty, které veřejně informují o své identitě, např. certifikáty X.509 (obsahují veřejně dostupné informace, jejichž pravost potvrzuje certifikační autorita). Naproti tomu jednosměrné identity jsou subjekty, které prozrazují svoji identitu pouze subjektům, které si sami zvolí a tím chrání své soukromí.

Pokud to dobře chápu, z hlediska uživatele musí systém podporovat jak uživatele, kteří se rádi svou identitou chlubí a rádi mají někde potvrzeno, že jsou to oni, tak uživatele, kteří se chtějí jen přihlásit ke službě, ale nechtěji být zpětně identifikováni. Můj systém umožní slepé přihlášení, kde uživatel neposkytne své id SP ale pouze IdP, a IdP za něj vyrobí jednoznačnou identifikaci v rámci konkrétního SP. z té identifikace nelze zpětně dohledat, o koho se jedná.

5. Systém pro práci s identitami musí zajistit možnost spolupráce různých technologií od rozdílných poskytovatelů identit (tedy musí být decentralizovaný).

Splněno 100%.

6. Součástí identifikačního metasystému musí být uživatel. Interakce uživatele s tímto systémem musí být realizována pomocí jednotného a zabezpečeného rozhraní.

Pokud hovoříme o ochraně proti phishingu, jednotné rozhraní je v zásadě proti tomuto požadavku. Ideální je, pokud jednotné rozhraní používá konkrétní uživatel. To mu v tomto případě poskytuje právě jeho zvolený IdP. 100% splněno.

7. Systém musí uživateli poskytnout jednoduchý a konzistentní výběr identity závislý na kontextu probíhající komunikace. Rozhodnutí o výběru identity musí být vždy provedeno uživatelem.

Uživatel si může zvolit svého IdP a v rámci IdP pak nějakou vlastní identifikaci. V rámci probíhající komunikace si může uživatel vybrat profil, který ke komunikaci vybere. 100% splněno.

Co jsem nesplnil?
bredy 23.7.2010 21:56  7359
RiderOkaj dobrý. Já sám považuju ty zákony (po tom, co jsem si je zběžně přečetl) za jakési teoretické cvičení, něco jako desatero božích přikázání. Možná jsou ideálem, ale nikdy podle mne nebude možné je dodržet v plném rozsahu. Píšeš, že existují systémy, které je dokáží doržet ve větším rozsahu. Možná, otázkou je, za jakou cenu.

Kritizuješ nedodržení 3. zákonu, s poukazem, že někde se to dělá bez nutnosti mít 3. stranu. Je legrační kritizovat systém identifikace založené na ověření u 3. strany s tím, že identifikace přes 3. stranu není správná. To je to létání bez mávání křídel. Možná lze se vyhnout třetímu kanálu mezi SP a IdP. Opravdu? Co když ne. Co když ten kanál tam tedy přímo neexistuje, ale existuje tam virtuálně? I přesto, že tam namalovaný není, tak systémem redirectů se ve skutečností nějaká data mezi SP a IdP předávají, akorát, protože jdou přes UA, musí tam být dobré zabezpečené. Jsi si jist, že ani takový systém neporušuje 3. zákon? Opravdu? Akademická diskuze.

A stejně tak modla non-auditing IdP. Život je plný kompromisů. Můžeš mít maximální svobodu, ale budeš bojovat s podvodníky, nebo maximální ochranu, ale nebudeš svobodný. IdP ti dává ochranu, ale bere ti svobodu, umožňuje ti jí část sebrat (svobodu na určité soukromí). Ale nejsi úplně bez nástrojů, právě jedna svoboda ti zatím zůstává, vybrat si zvlastního uvážení IdP, případně se sám stát IdP a problém s non-auditing IdP jsi právě vyřešil. Problém není se identifikovat, problém je prokázat, že ta identifikace není podvržená.

Jak jsem napsal, je to teoretické cvičení, akademická diskuze, vhodná opravdu spíš do přednáškové síně vysoké školy. Praxe ale ukazuje, že dobrá a rychlá služba je drahá, že levná a rychlá služba není dobrá a že levná a dobrá služba není rychlá. Prostě tohle je systém, který by měl pomoci v rozšíření právě jednoduchou implementací za cenu nižší obecnosti. Jednou doufám, že už si nebudu muset pamatovat tisíce hesel na různé e-shopy, a že i na Lopuch se přihlásím jménem a heslem do Seznamu.

Konečně, i ono slavné OpenID porušuje značnou část těch zákonů. Dokonce bych řekl stejné množství jako moje řešení. Jen je navíc ještě komplikované.
rider Rider - Asociace chovatelů antropomorfních koní 23.7.2010 15:35  7358
No, mám pocit, že v této fázi už jakákoliv diskuze nemá smysl. Vymyslel jsi n+1 autentizační systém, který podle mého názoru nepřináší nic, co by tady už nebylo. Zároveň má problémy, které některé jiné systémy už nemají, protože je buďto považuješ za nedůležité (např. 3. zákon identity) a nebo je pokládáš za neřešitelné (např. non-auditing IdP).

Pokládat některé aspekty za nedůležité je tvé svaté právo (já zase pokládám za nedůležité jiné aspekty, jako například jednoduchost technické implementace), je možné, že se všichni ostatní mýlí a ty máš pravdu, v tom případě tvůj systém bude úspěšný.

Že pokládáš za neřešitelné jiné aspekty je trochu zarážející, vezmeme-li v úvahu že jiné systémy je rutinně řeší, ale je jistě tvou volbou nestudovat stávající situaci v oboru, do kterého ses rozhodl vstoupit.

Prostě to naprogramuj a zveřejni a uvidíš. IMHO po tom pes neštěkne, ale budu rád, když se budu mýlit.


[ 4074 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt