Pisali sme to tu vyssie.
Nechcel som aby to vyznelo ako kritika teba alebo S.D. ze plactete neskoro a vtedy ste nekricali…- to bol skor taky povzdych ze na slovensku je to tak 
zmluvy z CRZ hovoria nieco ine a dokonca sa tam pise ze to nebolo obstarane ako sluzby ale velka cast ako licencia. Proste ANZU DESU je uzavreta (to co je v zmluve plati aj ked na stretnutich moze byt deklarovane cokolvek). Stat by sa mal zamyliset a dodat konecne aplikaciu na mobilnu autentifikaciu a autorizaciu na ktoru sa bude moct naintegrovať ktokoľvek bezplatne…
lubor, cize riesenie je kupene, a caka sa na noveho riaditela ? A este je zrejme problem HW. Je to tak ?
A este, a este mi nie je jasne, moze sa na NASES integrovat kazde OVM ? Predpokladam ze ano, je to teda aj open api ? Aspon technicky ?
Prvotna predstava bola, ze jednoducho na existujuci bod prihlasovania cez SAML pribudne aj moznost sa prihlasit cez mobil.
Cize integracia by ostala presne taka ako je dnes na single-sign-on, dokonca uz integrovane systemy by nemuseli nic zasadne menit (ak si odmyslime problemy s responzivitou web/apps). Co sa tyka autorizacie klikom, tak tam sa uvazovalo ci bude existovat aj centralny bod, na ktory sa da integrovat, aby si to pripadne nemusel robit kazdy sam.
Neviem kde toto zlyhalo, preco sa do toho odrazu montuje ako prerekvizita nejaky oauth, muk-p, hromada noveho hw.
1 Like
posledným klincom do bedne je zrejme to, že pán Miazdra ako PM za DEUS / DCOM, kttorý upiekol tento koláčik, je poradcom pani Remišovej a Antala, pokiaľ som dobre počul 
a podieľal sa na auditovaní všetkých IT projektov na MIRI
Veď to pribudlo na deve a fixe či?:
https://portal.vyvoj.upvs.globaltel.sk/sk/obcan
So SAML sa pracuje dosť ťažkopádne tak možno kvôli tomu riešia oauth/oidc ?
údajne mobilne eID malo dodať aj GT pre NASES, ale neviem to nájsť, lebo v crz nie sú presnejšie veci v novších dodatkoch, len sa tam píše o zmená IAMu ale nie je konkrétnejšie nič
v dodatku 5 sú nejaké popisy čo sa ma urobiť
https://www.crz.gov.sk/index.php?ID=603&doc=3819688&text=1
Zaujimave, ale zatial to vyzera len na flow (na desktope sa prihlasujem a namiesto eid pouzijem mobil). Nevidim tam cisto mobilny scenar (prihlasujem sa a robim vsetko cez mobil).
Toto som uz viackrat pocul, ale asi nerozumiem. V com to je tazkopadne? V klude moze byt jeden endpoint co SAML token prelozi na nejaky podpisany JWT token a potom uz fungujes ako chces. A toto je skor open api cast.
Beyond verbosity of exchanged data, if you compare the specifications you’ll find that OIDC was designed to work with the web while SAML was retrofitted to work on top of the web. For example, OIDC is also more suited for HTML5/JavaScript applications because it is easier to implement on the client side than SAML. As tokens are in the JSON format, they are easier to consume by JavaScript. You will also find several nice features that make implementing security in your web applications easier. For example, check out the iframe trick that the specification uses to easily determine if a user is still logged in or not.
Napr. získať SAML token z hlavného IDP v setupe federácie (IDP - keycloak - client) je možné len cez OIDC v keycloaku. Predlžovanie SAML tokenu (minimálne v setupe ktorý používam) je hodne ťažkopádne (riešia sa skryté iframy, popupy a podobne).
S JWT tokenom v súčasnosti asi edesk nezavolám 
Nice flex . Keď mám certifikát používateľa u seba môžem ho prihlasovať koľko krát potrebujem. Keď je potrebné od používateľa každých 20 minút vyžadovať aby zadával BOK, to už je horšie. (nepozeral som ako to robíte, ale teda SAML token asi nepredlžujete či ?)
Nehovorím, že neexistujú riešenia v aktuálnej situácii ani, že treba míňať miliony na to, aby tam bol oidc, len tvrdím, že z mojich skúseností je SAML ťažkopádnejší.
podla toho co viem toto vsetko plati. Cisto mobilny scenar je to iste a je jedno ci si domyslim pracu v mobilnom prehliadaci (prehliadac prihlasenie u SP->slovensko.sk prihlasnie mobilom-> mobilna app autehntificator->service provider prehliadac) alebo mobilnej aplikacii (mobilna aplikacia SP prihlasenie → mobilny autentifikator - > mobilna app SP)
- oauth - asi vsetci potvrdime ze SAML je tazkopadnejsi, nevidim dovod aby za oauth, oidc bolo treba minat miliony, a samozrejm oauth vyuzitie v mobilnych app bez nutnosti mat niekde web SP - ale to nechcem asi rozoberat lebo skoncime na debate web vs native app
- muk_p treba sa opytat v anasofte ale podla mna to nikto nechape ako prerekvizitu pre mobilnu autentifikaciu - skor si myslim ze sa chce napr preklapat sluzby na rest (napr edesk) pre mobilny svet a tak
- hromada noveho HW - prepokladam ze to je kvoli autorizacii klikom HSM srandy a podobne
- nemyslim si ze NASES kupil mobilne eID od GT, nakolko by to bola duplicita k uz akupenemu ANZU z DEUSu (toto si myslim ze je kamenom urazu preco sa to este cele nerozbehlo)
- podla mna si nekupili este ani sluzby upravy IAM pre integraciu DEUS riesenie na UPVS preto zamrzlo pripojenie DEUS
- ak sa nemylim a url neklame telom toto je odkaz na vyvojeve prostredie Globaltelu a nie NASESu, mate niekto aj mobilnu aplikaciu a postup ako sa to da vyskusat ?
- podla mojich info toto riesenie mobilnej autentifikacie ma GT pripravene uz viac ako rok a pol na nasadenie dale nikto to nechce kúpiť.
- dokonca zevraj aj na spominanej prezentacii ÚPVII v 2018-2020 prezentovali hotove riesenie uz napojene na UPVS
- prave tieto prezentacie mali byt urychlovacom podpisu zmluv medzi DEUS a NASES
- koniec koncov asi by ste sa mohli spytat tych chalanov co to pre globaltel robili
2 Likes
Ja som si to schvalne skusil na tom DEVe slovensko.sk a asi to nie je dorobene, lebo na mobile to chce tiez skenovat QR kod
O tomto presne to je. Predstava, ze niekde vznikne nativna app, ktora bude vyhladne “orchestrovat” sluzby na klientovi a token teda bude len v app je podla mna velmi uzky scenar. Ovela skor vzniknu web alebo nativne aplikacie, ktore pojdu cez API svojich tvorcov. A owrapovat si aj SAML/SOAP nie je az taka strasna praca.
Anasoft s tymto ma co? To je pre mna novinka. V kazdom pripade GT sa tvari, ze na mobilny treba oauth a ten oauth je uz v muk-p a na muk-p treba hrozne vela hw. Klasika.
Aha pardon, sa mi zdalo, že som to videl aj na FIXe. Pozeral som to znovu a nie je to tam, takže je to len na DEVe.
existuje niekde mobilna appk a pouzivatel pre testovacie zaregistrovanie zariadenia ked to testujes ? ci len cisto z vizualu ?
podla mojho nazoru a toho co vidim bude stacit kliknut na QR kod a authentifikacia prebehne
<p> Ak sa prihlasujete na tomto zariadení a máte na ňom nainštalovanú aplikáciu<strong>slovensko.sk - Prihlásenie</strong>, stačí kliknúť na QR kód a aplikácia sa spustí. </p>
cize asi skor este nedorobok
asi sme sa neporozumeli a dufam ze to teda takto nemaju na slovensko.sk vymyslene:). Web SP som myslel SP v intenciach SAML. Token sa samozrejmu musi dat vyuzitim ostatny aplikaciam na a nevidm ani dovod preco nie a ani by mi nenapadlo tymto smerom uvazovat takze dufam ze to ani tak nieje.
Anasoft je dodavatelom MUK-P. Prerekvizitou MUK-P bolo mat oauth server pravdepodobne kvoli autorizacii na preklopenych sluzbach zo SOAP do REST. Ale neviem preco by mal byt MUK-P prerekvizitou pre mobilnu autentifikaciu a autorizaciu a ani som to nikde nenasiel v oficialnych dokumentoch takuto požiadavku ze pokym nebude muk-p nebude mobileID. Skor ak maju zamer na neaku mobilnu aplikaciu (napr nativna eDesk app) tak maju prerekvizitu mat prerobene existujuce sluzby eDESK do REST s Oauth autorizaciou. Ale tam stale nevidim suvis s mobilnym eID
Opäť a úplne polopatisticky: riešenie DEÚS je v prevádzke, riešenie Nases nie je objednané.
Toto je dosť trápne. Je úplne jasné, že koláčik sa piekol o hodne vyššie.
A “keď som dobre počul” máš zrejme vlohy pre dramatizáciu, ale je to už dlhšie tak známa info., že je aj tu vycapená: Audit 50 it projektov - #74 by Lubor
Ale iste že to nevieš nájsť v CRZ, lebo to nie je objednané, ako som tu napísal a takto to prezentoval aj Nases na stretnutí.
Nad SAML pracuje dnešné SSO, čiže každý správca štátneho webu už si to integroval. Nové riešenie mID skrátka musí byť do toho zapojené, ináč to nedáva zmysel.
Nie. Autorizácia klikom nevyžaduje žiadne takého nové srandy (a to práve preto, že to nie je nový podpis). Ak ich tam niekto pchá, rád si nechám vysvetliť prečo je to nevyhnutné.
“Podľa mojich info” je to presne naopak. Vo chvíli kedy si DEÚS išiel robiť vlastné riešenie sa niekomu zdal dobrý nápad spraviť z toho centrálne. A to aj preto, že niektorí konatelia GT sú notoricky známi rečami ako už všetko majú hotové, len sa to potom nejako skomplikuje. Ja som takto v roku 2011 počul že “ÚPVS je celé hotové, už len nainštalovať a môže to byť v prevádzke, stačí opäť spustiť projekt, aká škoda že sa to zastavilo”. Haha.
Keby sa používal napr. keycloak tak by to nemusel byť taký problém prehodiť. Chápem, že asi budú zvýšené náklady. Možno priestor tam dať OSS ? Možno to majú nejako vymyslené, či je to podmienené OIDC ? nie je to OIDC len medzi UPVS IAM a mID a potom sa to prebaluje do SAML ? (špekulujem)
Na toto neviem dobre odpovedať, bolo by treba pozrieť, ako je k IAM ÚPVS pripojený eIDAS node.
Pripojenie eID MVSR vyzerá byť čisté SAML, viď. https://prihlasenie.slovensko.sk/login/samlsso/eidinit -> https://eidas.minv.sk/idp/profile/SAML2/POST/SSO
Edit: a eIDAS node tak isto: https://prihlasenie.slovensko.sk/login/samlsso/eidasinit -> https://eidas.slovensko.sk/EidasNode/ServiceProvider
1 Like
asi pomaly chapem, podla dokumentov zaplatil DEUS a ma bezplatne posunut licenciu NASESu. Zrejme su v hre nejake implementacne prace ale uz nie licencia.
Ak by teda novy riaditel podpisal zmluvy a urobil objednavku tak bude mobilne ID ? ( ciste technicky, mimo etiky a prava. )