Robia okolo toho trosku tanecky, ale toto mne celkom jasne hovori, ze to je priprava, aby IAM proste nahradili.
Bol by som v tejto téme - IAM (aj na základe osobnej skúsenosti) veľmi opatrný.
-
Nie len v tomto, ale dokopy myslím v troch projektoch je dnes napísané, že IAM sa bude rozširovať o modul OAuth2.0 a OpenIDConnect (delegované na projekt CAMP). Takže nie len SVM, aj tento projekt má závislosť na CAMP a tam je ešte stále v hre existujúci dodávateľ ÚPVS s riešením MUK-P (= myslené ako “prvá fáza” CAMP - APIGW engine). Aspoň takto je to v pokladoch, ktoré ako verejnosť vidíme. Ak je to inak, tak sa k odbornej verejnosti táto informácia/zmena zatiaľ nedostala. Tu len na chvíľu odbočím.: Na pracovných skupinách MIRRI sa už pomaly vyše pol roka rieši kadečo, ale plány MIRRI a čo bude robiť SK.IT - zdieľané formou odbornej a hĺbkovej architektonickej diskusie - ani raz.
-
Späť k téme. Ten odstavec, ktorý si uviedol - podľa môjho názoru hovorí niečo iné. Modul pre správu oprávnení tretích strán v MUK-P (= prvá fáza CAMP) nie je, logicky sa tak objavil tu. Môže to napovedať, že CAMP v pôvodnom rozsahu sa už nebude dodávať (ale nemusí - pravda je, že spoľahlivé informácie od MIRRI zrejme nemáme - viď vyššie). Odstavec prakticky hovorí, že bude možné synchronizovať “oprávnenia z upvs” do modulu, z ktorého ich budem vedieť delegovať na tretie strany (aby nie len v mojom mene, ale aj len v rozsahu mnou definovaných oprávnení - vedeli riešenia tretích strán volať openapi služby). To nie je náhrada za IAM, ani jej predzvesť. To je nadstavba.
Rozhodne by som zvyšujúcu sa závislosť na existujúcom IAM (a jeho dodávateľovi) riešil ako závažnú pripomienku (a až následne - keďže termín pre pripomienky je už za dverami - eskaláciu na PS). A počkajme si na výklad a argumentáciu zo strany MIRRI a NASES ako to vlastne plánujú.
1 Like
Ano, toto som si myslel aj ja pokym som si neprecital tu poslednu vetu. Je to take salamunske riesenie, ktore hovori, ze mozno to bude aj treba cele vymenit. Neviem ako si chce SKIT (lebo toto bude robit SKIT) vydupat tuto sucinnost s GT, cize mne to vychadza tak, ze to proste spravia znova.
Ano toto mam ako genericku pripomienku, ze “ako toto riesi / mitiguje vendor lock UPVS”.
1 Like
Tá posledná veta sa dá istotne vyložiť aj tak, že žiadny dodatočný priestor na výmenu nevytvára - hovorí len, že akýsi synchronizačný mechanizmus oprávnení (čo nie je overenie identity - core funkcionalita IAM-u) existuje. A ak ho súťažiaci nebude vedieť použiť, musí dodať vlastný.
Samozrejme, ak v tom priestor vidíte - neberiem ho. Ale v takomto dokumente je nebezpečné nechávať priestor na šalamúnske formulácie. Je to bianko šek s možnosťou svojvoľne si vysvetľovať zameranie projektu počas jeho realizácie. Preto súhlasím - generickú pripomienku na vysvetlenie dajme, no strážme si v odpovedi aj toto chýbajúce vysvetlenie. Typický problém s generickými otázkami je, že sa na ne dá genericky odpovedať 
Pripomienkovanie bolo vyhodnotene:
M-UPVS_Vyhodnotenie_pripomienok.pdf (316.9 KB)
Zopar poznamok k tomu:
- Ako problematicke vidim nerozdelenie zakazky na casti. Myslim, ze toto sa bude dost tazko obhajovat, kedze niektore casti (napr. vyhladavanie, analytika, CMS) su dnes dostupne ako samostatne produkty alebo sluzby. Toto zjavne limituje konkurenciu (bud dodas cele alebo nic) a zaroven je zrejme, ze aj vysledok moze byt nie dobry (specializovana firma, ktora dodava najlepsi ciastkovy produkt/sluzbu sa nevie prihlasit). Pri takomto type obstaravania by bola, ze sa objedna systemovy integrator (a to nech v klude je aj SKIT) a casti samostatne. Vsetkym je vsak jasne, ze toto bude cele dodavat SKIT, co je smutne, lebo prave preto, ze ide o dodanie statnou firmou, by mala byt este vacsia miera transparentnosti a vysvetlovania, lebo su v obrovskej vyhode voci zvysku trhu.
- Nezverejnenie navrhu zmluvy povazujem za uplnu haluz. Specialne, ked hovoria, ze pojdu podla vzoru MIRRI, by s tim vobec nemali mat problem. Pri beznom obstaravani navrhy zmluvy je. Opat, v tomto pripade by mali ist nad ramec toho co sa bezne pri obstaravani pozaduje od trhu a nie naopak.
- Explicitne som sa pytal, ci bude v ramci projektu spraveny responzivny dizajn schranok na slovensko.sk. Vraj nie. Toto bude este zaujimave, lebo na dalsom pripomienkovanie (slovensko v mobile) tvrdilo SKIT, ze urcite to tam je (mimochodom to je jedna z prerekvizit, aby mohli robit nativnu aplikaciu). Som zvedavy ako toto dopadne.
1 Like
Pokial dobre viem v ramci modernizacie UPVS je poziadavka na nove portfolio klienta (nieco ako osobna zona FO/PO), ktoreho sucastou su aj zakladne funkcionality schranky. Cielom modernizacie nie je prerobit celu schranku, kedze obsahuje mnozstvo funkcii, ktore by to ovplyvnilo a aktualne ju ma nastarosti sucasny vendor.
Portfolio klienta ma byt responzivne, tym padom aj cast funkcionalit schranky by mala byt pristupna aj z prehliadaca v mobile.
Ano toto mi potvrdili aj v NASES. Lenze co su tieto “zakladne funkcionality schranky” ? Vie to niekto? Ci vsetko teraz budeme robit tak, ze dostaneme X milionov eur na “macku vo vreci” a vybavi sa to formulkou “bude to predmetom analyzy”.
Ja som fakt zvedavy ci tieto analyzy niekto niekedy uvidi a kto a kedy rozhodne, aky bude scope.
1 Like
Napr. odpovedanie. Co este par mesiacov dozadu nezvladalo.
Kedze kazdy pouzivatel ocakava automaticky tu najlepsiu skusenost, aku ma z inych webov (pre vyhladavanie spravanie ako Google, pre eshop ako Alza/Amazon atd.), tak je jasne, co ocakava od slovensko.sk - aby mohol pracovat so schrankou ako emailom.
A nie ze pre vytvorenie novej spravy sa musim preklikavat cez x dalsich stranok, ktore ma potom zas naspat hodia do schranky. Uplny nonsens.
No vyzerá to, že sa urobí len “frame” a do neho sa bude embedovať súčasná schránka 
a reálne sa prerobí len statická časť slovensko.sk, čo je CMSko a zrejme aj vyhľadávanie služieb s konštruktorom (snád aj s podporou na nové eFORMs)