Open API štandardy

Výborne, môžme to prebrať dnes na PS1.

Žiaľ dnes nebudem môcť byť na stretnutí PS (mám dovolenku), v krátkosti možno ešte nejaké vstupy do diskusie.:

  1. K zoznamu funkčnosti WebAPI vrstvy - možno by stálo za úvahu aby boli publikované endpointy implicitne chránené proti DDoS útokom. Niečo na spôsob https://www.telekom-icss.com/business-areas/internet-transport/ddos-defense/backbone-security alebo https://aws.amazon.com/shield/ . Netvrdím že to tam byť musí, berte len ako návrh (brainstorming) - v každom prípade ak to nebude tu, tak si musíme povedať kde.

  2. K diskusii či “WebAPI vrstva ako centrálne riešenie, alebo ako iPaaS” by som sa prihovoril k nasledovnému (aj v duchu “natívnej cloudovej architektúry” - viď výstup PS Architektúra).: Pokiaľ si urobí centrálna úroveň dobre svoju robotu a publikovanie služby na WebAPI vrstvu bude rýchle a lacné ( = čo najviac automatizované), tak nie je pre mňa - ako pisateľa aplikácie - zaujímavé, aby som sa musel zaoberať konfiguráciou iPaaS riešenia pre publikovanie endpointov. Samozrejme, nechať si otvorený aj režim iPaaS v prípade (veľkých) systémov so špecializovanými požiadavkami na prevádzku a konfiguráciu WebAPI vrstvy je logický krok.

…len pre info…

…v ramci OpenData API ITMS2014+ (citanie publikovanych dat) mame samozrejme urobeny monitoring, aby sme vedeli, co sa cita, v akych objemoch, pocty requestov, ake mame odozvy a pod. Nejaky rate limiter tam zo strany apliakacie nie je, nakolko doteraz nebol potrebny a nevyskytli sa ziadne vykonove problemy…nie je tam ani ziadne riadeni pristupov, nakolko nech to cita, kto chce…ITMS2014+ bezi v DataCentre a tam viem, ze maju nejake prostriedky, ktore pri “podozrivom” spravani odrezu komunikaciu…

…v ramci ITMS2014+ sa pripravuju aj OpenAPI (t.j. otvaraju sa API na zapis dat priamo do ITMS2014+) a tu sme si museli samozrejme urobit nejake zakladne veci ako riadenie pristupov k tymto API, aktualne velmi jednoduche, nakolko sa uvidi aky bude zaujem o tieto sluzby…myslim, ze nebude problem tam zaviest aj metriky a pod…

p.s. ten post je v zlej osobe pisany, nakolko uz som mimo ITMS2014+ a aj info nemusia uplne sediet, ale cielom bolo poukazat, ze tie genericke poziadavky GW by mal riesit (ja k tomu donuteny) kazdy IS, ktory spristupnuje nejake API a chce mat o nich nejake info, ze co sa tam deje a pod.

Som myslel, ze mechanicke preklapanie (elektronizovanie) papierovych procesov je prave to co nechceme: Mantra “ked to s papierom robim HENTAKTO, tak aj s elektronickym suborom to chcem robit presne HENTAKTO” rozvoju eGov moc nepomaha.

To si si trosku zjednodusil. Viem si predstavit aj ovela zlozitejsi sposob v elektronickej forme ako v papierovej. Napriklad ked sa nieco da podat anonymne a odrazu sa to schova za prihlasovanie eID/tokenom.

Inak toto je dost nepodstatna vec pre tento topic. Na standarde toho, ako ma OpenAPI fungovat to vobec nic nemeni.

nad tou definiciou Otvorenych API by som sa zamyslel a to v nadvaznosti na ukazovatel NKIVS:

Podiel informačných systémov verejnej správy, ktoré poskytujú otvorené API 99.9 %

…aby sa nestalo to, ze na write toho bude spristupneneho ako safranu, vsetko bude na read a ukazovatel bude splneny…mam pocit, ze pri definovani toho ukazovatela bola urcita predstava…

Vyhláška o autentifikačných certifikátoch v MPK, do 1.12.:
https://www.slov-lex.sk/legislativne-procesy/SK/LP/2017/815

Predstava Nasesu je taká, že pre každú aplikáciu využívajúcu OpenAPI bude vydaný jeden AC (a založený jeden technický účet), následne používateľ udelí splnomocnenie pre túto aplikáciu (a prevádzkovateľa tejto aplikácie) v jeho mene pristupovať ku službám.

Tento prístup môže fungovať, ak takéto splnomocnenie je možné udeliť “autorizáciou použitím funkcie IS”, t.j. nie je nevyhnutné použitie KEPu.

Dávnejšie riešená otázka “kto pristupuje ku službe” v tomto riešení imho je jasne zodpovedaná, že ku službe pristupuje prevádzkovateľ aplikácie - čo aj dáva zmysel. Po udelení splnomocnenia totiž prostriedky, čas a spôsob prístupu k API kontroluje výlučne prevádzkovateľ aplikácie.

Nie je mi úplne jasné, ako v tomto bude fungovať scenár, kedy webová aplikácia chce pristupovať k API pre aktuálne prihláseného používateľa a iba počas trvania jeho session.

Ak sa tieto veci zodpovedia, proces vydávania AC nie je treba nejako špeciálne zjednodušovať, lebo používateľ aplikácie tretej strany AC vlastne vôbec nepoužíva.

K vyhláške zatiaľ tieto pripomienky:

  • §1.3.f,g,h - Čo presne má byť “informácia o rozsahu oprávnení”? Pri OpenAPI by snáď mohlo ísť o všetky potrebné “role”/scopes, ktoré potrebuje na svoju činnosť. Tu však sú 2 rozdielne veci: prístup ku službám “za seba” a prístup “v mene používateľa”. Zároveň vyhláška teraz necháva priestor tieto role popísať slohovou prácou, čo teda určite nie je zámerom. Celkovo toto dávať v žiadosti o AC je zbytočnosť, lebo rozsahy oprávnení sa nevzťahujú na certifikát, ale na prístup aplikácie a sú riešené v rámci integrácie a jej papierovania.
  • §2.2 - Celé zle. Obmedzenie platnosti AC na 2 roky je nezmysel. Jednak toto nie je podpisovací cert., čiže nie je potrebná žiadna validácia ním vykonaných vecí po ukončení jeho používania a dvak sa jeho použitie neriadi overovaním jeho doby platnosti, ale tým či je zapísaný v registri, alebo nie. Zároveň hovoriť o tom kto a ako “vydáva” certifikát vôbec netreba, skrátka sa má určiť aká je položka v certifikáte. Keď už je potrebné hovoriť o životnosti certifikátov, tak navrhujem 20 rokov. Mimochodom, zo zákona nikde nevyplýva, že po uplynutí doby uvedenej v položke certifikátu “valid-to” by AC mal byť automaticky zrušený, alebo že ho v tomto prípade má/môže Nases zrušiť…
  • §3 - Jednak nič nerieši a je teda zbytočný, a popri tom ani §59.2.f zákona o eGov nedáva zmocnenie upraviť vydávanie zoznamu platných AC vyhláškou. Skôr je treba vydať metodické usmernenie (alebo štandard?), že OVM majú prístup s AC riešiť pomocou STS tokenu a nikdy nepotrebujú priamo vidieť AC, ani zaujímať sa o jeho vlastnosti (napr. či je platný).
  • §4 - akosi keď MPK končí 1.12., nepredpokladám že by účinnosť vyhlášky bola reálna skôr ako 1.1.2018
  • príloha.1.a - Dĺžka kľúča nech je 4096, aspoň to upokojí fanatikov túžiacich po obmedzení platnosti AC na max. 2 roky.

K OpenAPI bolo včera stretnutie PS1 a PS2 v Nasese. Hlavné body:

  • AC majú byť vydávané ako píšem v predošlom príspevku
  • na základe AC vydá STS token, ktorého atribúty sme podrobne prebrali, je tam všetko čo potrebujeme pre OpenAPI - Actor - aplikácia pristupujúca k OpenAPI a jej prevádzkovateľ, Subject - v mene ktorého používateľa je prístup vykonávaný, Role - scopes pre OpenAPI
  • riadenie prístupu k el. službe je 2 úrovňové - 1.level: v rámci STS tokenu sú uvedené role, na ktoré má v mene Subjectu aplikácia prístup, 2. level si má el.služba riešiť interne - povolenie daného Subjectu vykonať konkrétnu funkciu
  • momentálne je možné v STS uvádzať iba role pre ÚPVS, čiže treba doriešiť či/ako sa majú registrovať a používať iné role/scopes
  • momentálne Subject pridelenie oprávnení (rolí) pre Actora môže urobiť pomocou el.formulára na ÚPVS (môj osobný pohľad: anti-UX riešenie - používateľ skoro nikdy nechce prideľovať oprávnenia pomocou comboboxov “všetky role” a “všetky appky”) - potrebovali by sme flow v ktorom konkrétna aplikácia navádza používateľa na udelenie konkrétnych oprávnení - skrátka normálny Authorisation krok ako je v OAuth
  • centrálny API GW je v nedohľadne (@jsuchal tuším našiel v jednom dokumente že je plánovný na rok 2022), čiže ak sa má prakticky začať OpenAPI realizovať, tento komponent si každý bude robiť svoj

Na predošlom zasadnutí PS1 som k základom OpenAPI mal takýto dokumentík.

Ja dodam nejake dalsie info k tomu co chyba na to, aby to mohlo zacat fungovat dobre “zajtra”:

  • je to postavene na SOAP/WS, ktore su pomerne kosate, podpisuju sa requesty, niektore novzie jazyky na toto uz nemaju ani kniznice, ale da sa s tym zit. Z mojho pohladu je nejaky oauth/openid connect v tomto momente nice-to-have a vzdy sa da spravit wrapper.
  • urcite treba nejaku (centralnu?) krabicku na udelovanie opravneni z pohladu pouzivatela. Momentalne by sa to dalo nejako obijst, ale vyzadovalo by to vzdy dost netrivialnu integraciu pre tretie strany (web SSO).
  • specialne v pripade, ze sa udeluje opravnenie na dlhu dobu/trvalo/offline by mal existovat nejaky sposob ako tie opravnenia niekde vidiet a pripadne vediet jednoducho zrusit.
  • urcite narazime na problem, ze sa v tom tokene prenasaju osobne udaje (minimalne RC osoby)
  • integracia momentalne ide cez VPN tunely, co znamena dalsie komplikacie pre integrujuce sa strany. Toto treba urcite zjednodusit. Ako procesne tak snad aj technicky.
  • pridavanie roli/scopes pre NASES moze sposobit procesne problemy. aj ked nejde o nic strasne komplikovane, je to nieco nove navyse co by museli zastresit.

Napriek vsetkemu v principe chyba velmi malo, aby to mohlo velmi rychlo zacat fungovat. Na API GW cakat netreba, ci sa tokenu da verit je operacia len overenia podpisu na strane agendoveho systemu (na to by mali byt opat kniznice/hotove riesenia).

Prečítal som diskusiu - nemôžem sa ubrániť dojmu ze sa vymýšľa koleso - xroad.

Schvalne, na akom standarde je postaveny X-road?

Takto som sa na to nepozeral. Išlo o to ze pokial by sme reálne prebrali oss xroad, a umožnili decentralizovane nasadenie a integráciu - tak to bude rýchlejšie ako “manévre” s muk a vymýšľaním centrálnej autorizačnej komponenty. Pretože aj ked sa vymysli, potom začne ťahanica kto bude gestor, či nases alebo niekto iný. Pričom do toho vstúpi Mvsr ako vždy ktoré oznámi ze okrem svojho vlastného nebude uznávať žiadny iný … a sme v roku 2020.

Ja som mieril inde, x-road ako ho mam ja nastudovany je nieco ako service bus/secure kanal na soap medzi dvoma systemami, ktore si ne/doveruju (a to sa deje na zaklade nejakych prav cez PKI) ale vobec nikde tam nevidim podstatu OpenAPI. A to je, ze nejaky system tretej strany moze robit za mna nieco co mu niekde dovolim.

1 Like

No tak na toto netreba xroad. Akoze ano je pekne, ze to tam ma out-of-the-box logovanie, rozbehas to (asi) za chvilu, ale v principe je to vymysleny standard, ktory pouzivaju len oni (a ich zakaznici). Naproti tomu je taky WS-Trust + OnBehalfOf alebo OpenID Connect celosvetovo uznavany standard s mnohymi implementaciami a riesi presne tento OpenAPI usecase.

Obavam sa, ze tu sa nejake centralnejsej skatulke, kde budu ulozene kto komu udelil prava na ake ukony nevyhneme. Toto je per-user nie per-system. Tato skatulka je dnes IAM na UPVS. Funguje sice len v ramci UPVS ale princip je uplne rovnaky, vydava token, ktoremu potom veria systemy, ktore veria IAMu. Bez akejkolvek dalsej komunikacie s IAMom. Navyse je to standard, ktory tu je roky (a asi aj ovela dlhsie ako x-road samotny)

1 Like

Práve z toho centrálneho Access managera mam obavu. Ale Ok.

Aj ja, ale xroad podla mna riesi iny problem, preto to maju trosku lahsie a jednoduchsie.


Existuje na toto aj decentralizovany model, v principe moze tych skatuliek s opravneniami existovat viacero. Dolezite je, aby ich public klucom verili jednotlive systemy, ktore budu vystavovat API. Z pohladu pouzivatela by som vsak nechcel mat X roznych miest kde budem spravovat pristupove prava k nejakym subsystemom MV vs zvysok sveta. A preste toto sa stane aj pre komponent Moje Data, to je to iste v ruzovom len pre read-only. Tam to treba spojit a hotovo.

…vznikol nejaky uceleny navrh standardov? ak ano, kde ho mozem najst?..

Ucelene je to spisane asi iba tu : https://wiki.finance.gov.sk/display/PS1/OpenAPI . Toto bolo prezentovane aj na PS1.

dik…aky je dalsi plan? kedy cca bude existovat finalny standard?

Podrobny casovy plan podla mna nie je. Za mna osobne… aby sa dalo argumentovat so vsetkymi tymi strategickymi dokumentami, kde sa pojem OpenAPI casto nachadza, ale nikde nie je definicia(a este dokonca aj existuje OpenAPI pojem ktory znamena nieco uplne ine), tak by sa mala schvalit aspon minimalna definicia vid. napr. to co som poslal ak na nom bude konsenzus.
Tym vznikne viac casu, nech sa jednotlive kapitoly lepsie specifikuju a ide sa do podrobnosti s nimi, ale aspon zakladny ramec by bolo fajn mat cim skorej tj. do konca roka nech to ide na PS1 hlasovanie.

Ja osobne vidim najvacsi problem momentalne v tom ze projekt, ktory to ma systematicky riesit je naplanovany 2022? Akoze dovtedy sa to tu bude nejako bastlit s tym co mame? Ja fakt nerozumiem ze preco projekty, ktore v principe s nikym nekoliduju a mozeme ich povazovat ako centralne bloky na ktore sa maju ostatny integrovat nejdu v prvej vlne ale az nakonci