Sa WCF na gRpc, jednostavna autentifikacija

Pokusacu da sto bolje formulisem pitanje odnosno izazov koji imam mada ce biti tesko sobzirom da ni sam ne znam tacno sta tacno trazim. Takodje, nisam bas na ti ni sa svim konceptima koji su trenutno implementirani, ali imam pristup source code-u tako da mogu da odgovorim na podpitanja sa slucaj da iko ukapira sta mi treba :)

Naime, projekat na kom radim je manje vise klasicna ASP.NET aplikacija (.net 4.8, mvc, wcf, mssql, iis) gde Frontend komunicira sa backend-om preko brojnih WCF servisa. Frontend je jedan, ali postoji nekoliko backend modula pa zbog toga vise WCF servisa. Autentifikacija izmedju klijenta i servera je Kerberos i izmedju njih nema nikakve razmene nikakvih tajni u vidu privatnih/javnih kljuceva, tokena i sl. Bar ne eksplicitno, sta kerberos u pozadini radi ne znam, ali za ovu problematiku nije ni bitno. Server dobije kroz request info sa kog servera dolazi ulogovani user i podatke o user-u. Ovakav vid autentifikacije je izabran jer u nasem slucaju omogucava jednostavnu autentifikaciju u okruzenju gde ima na desetine instalacija. U suprotnom, bilo koja varijanta sa razmenom kojekakvih tajni gde se tajne razlikuju po instalaciji je preveliki balast za odrzavanje.

E sad, startuje novi projekat koji zahteva novi backend modul odnosno novi service preko koga ce klijent i server da komuniciraju i zelja je da to bude .net 6. Tamo nema WCF-a vec je preporucena tehnologija gRpc. Moj zadatak je dakle da ispobam varijantu gde je klijent 4.8, a server 6.0 koristeci gRpc. E sad, stizemo do problematike. gRpc koristi HTTP/2 protokol koji nije podrzan od strane Kerberos tjst Windows auth tako da moram da trazim alternativu. Lista podrzanih tehnologija za authentifikaciju je sledeca:



Probao sam JWT Authentifikaciju i to radi, ali zahteva da JWT auth servis i backend servis cuvaju private key sto je ocenjeno kao deal braker. Onda sam pogledao Azure AD i vidim da i tu klijent salje jwt token za koji da bi se generisao takodje treba neka tajna.

I tako se ja pitam, postoji li neki (siguran) nacin da klijent i server komuniciraju uz pomoc gRpc-a koji ne ukljucuje privatne kljuceve, tokene i sl?

Hvala!

Da u pravu si, vidim da ne podrzava manje od http/2



Mozes da komuniciras kako hoces, sigurno, manje sigurno, nesigurno... zavisi od zahteva i okruzenja.
Ako je neka private mreza i ako se sloze kocke, mozda mozes da se provuces bez icega, ali to je ultra retko.

U header moze da se stavi sta hoces: JWT, neki simple auth preko Base64String, gde 'zapakujes' user/pass ili sta vec... Token dobijen od nekog servera je sigurica, a ovo drugo smesno, ali kod resursa se token ili user/pass iz zahteva/poruke moraju proveriti u nekoj db i autorizovati. Taj servis koji koristite to radi, koristeci verovatno liste account-a na win serveru. Nisam se nikada susretao sa njim, a verovatno je matoro resenje.

Ako imas gomile apps, mikro servise... svakako treba neki centralni identity servis, solidno resenje je IdentityServer4, ako uspes da ga prilagodis svom sistemu, a moze i nesto na cloud-u, Azure AD ili AWS Cognitio.

Koliko razumem, tvoji u firmi nece nista da menjaju, sto znaci da cete se nacekati za NET 6.

Kao neko ko je upravo pusto custom made Identity Server 4 OAuth server u produkciju, mogu da ti pomognem oko razumevanja nekh stvari vezanih za "tokene", pocev od JWTa. Windows Authentication polako ide u zaboraav jer zahteva nekoliko round trips izmedju klijenta i servera, sto je protivno http/2 i http/3 filozofiji pa nikad nije ni napravljeno (tehnicki nista ih ne sprecava da naprave round trips unutar http/2 pipe-a ali ih ocigledno mrzi da se cimaju zbog tamo nekih non-cloud usera).

RSA je samo jedan od nacina da se zastiti token, mi ga koristimo zato sto je u osnovi sigurniji jer je baziran na PKI tehnologiji a mi imamo public facing SSO (single signon) portal za musterije firme, medjutim moze podjednako da se koristi i HMAC provera. HMAC provera se bazira na tome da authentication server koji izdaje tokene i client koji ga prima imaju zajednicki "secret". Kad kazem client ne mislim na end usera, mislim na clienta authentikacije, tj servis koji zahteva da enduser bude authenticated i koji ce proveravati da li je token ispravan, u tvom scenariju to bi bio gRPC server (ovo je deo OAuth terminologije). Po meni je to malo manje secure od RSA, ali dok god ne saljes secret u browser sesiji samom end useru, to je u osnovi security through obscurity i radi sasvim fino kad su i identity server i svi kllijenti pod tvojom kontrolom pa ne moras da saljes secret nikome sa strane.

Ne treba da vas plasi sto identity (oauth, jwt auth, itd) server ima private kljuc, taj private kljuc NIKADA ne napusta identity server, od identity servera mozes da dobijes jedino public keys, i svako iz audience-a ko treba ima pristup serveru moze da dobije public keys, da bi mogao da validira potpis u tokenima. PFX (private+public) cert koji identity server koristi za potpisivanje ne mora da bude komercijalni, moze da bude i self signed cert, ja sam npr instalirao self-signed cert koji istice 12/31/2099, tako da ne postoji neka velika prepreka u primeni ovog resenja.

Cisto da vidis da ovo sljaka, ovo je npr public key demo oauth servera od Duende-a (oni su napravili Identity Server biblioteku): https://demo.duendesoftware.co...nown/openid-configuration/jwks (ovo je standardni URI nakalemljen na token issuer-a, pogledaj kako token izgleda u jwt.io za detalje). kljucna polja ovde su ti kid (key id, koji se pominje u JWTu), e i n (sto su eksponent i modulus javnog kljuca). Na osnovu toga klijent generise RSA public key context i validira signature, a zbog prirode PKI ne moze da generise private key da bi mogao da pravi fake tokene. Ako je potpis validan zna da je JWT izdao bas taj identity server, ako veruje serveru verovace i tokenu koji je server izdao i pogledace claims da vidi o kome se radi. Kad ti njihov demo server izda JWT token, ti mozes da skines ovaj public kljuc i proveris potpis i samim tim mozes da verujes da je Duende server identifikovao end usera. Na istom principu, samo sa drugim launch i token URIs rade i Azure AD, i Google Authentication i armija drugih komercijalnih OAuth resenja, kao i jos veca armija company-wide identity resenja kao sto je ono koje sam ja uradio. kao sto je dejanet napisao mozete da uzmete identity server 4 quick start i da napravite svoj authentication server od toga, a mozete i da se uvezete sa google API ili Azure AD, napravite sovju "aplikaciju" (i u slucaju Azure-a svoj tenant) i logujete korisnike preko njih.

That being said, ovo je preporuceni sistem, ali nije jedini, on samo znaci da je interkonekcija sa drugima "laksa" jer se svi medjusobno razumemo jer svi znamo sta je RFC7519 i kako treba da izgleda JWT i sta znaci Bearer authorization header. Ima tu jos sitnica tipa tenancy, audience, claims, itd, ali ovo je sustina.

Downside svega ovoga je sto su sve ovo osmisljavalli i pravili frontenderi te je sve ovo prioritetno osmisljeno za browser primene. Kad si u situaciji da pravis Windows desktop client/server resenje, forsiranje korisnika da iskoci u browser da se uloguje je big nono. Umilostivili su se da nam ostave nesto sto se zove "password grant flow", iako na sva usta trube da to ne bi trebalo da se koristi (jer ti kao client imas dodira sa enduser lozinkom), ali je password grant tu da ostane, sasvim sigurno jos dugo zbog API pristupa. problem je sto je, u ovo doba cloud histerije, OAuth nastao kao potreba za "delegated authentikacijom" sto ne postoji kao pojam u internom kompanijskom kruzenju gde su svi useri vec authenticated.
Ono sto mozes da uradis je da implementiras samo OpenID Connect server side (to je authentication deo OAuth standarda ali moze da radi i sam za sebe), vise detalja imas ovde: https://openid.net/connect/ ali iskreno ne znamo koliko to sve moze da se direktno integrise u Active Directory. mislim da ADFS (Federation services) za Windows Server 2016+ podrzava direktno OpenID connect (ako sam dobro razumeo to bi znacilo da ti ADFS moze dati JWT za trenutnog korisnika), ali ja vec godinama polako napustam Windows tako da tu ne mogu mnogo da ti pomognem. Probaj da guglas i vidis.


Takodje, "Bearer" token je samo jedna klasa tokena, tebe niko ne obavezuje da koristis RFC7519 i JWT tokene u Bearer authorization headeru. Mozes da napravis svoj authorization sitem i da ga upucas u middleware pipeline u asp.net core aplikaciji (koja je ispod tvjih gRPC metoda). Da, mozes da imas stvari tipa HTTP header Authorization: tdusko 123464566-neki-moj-blob. Dok god i pozivalac i pozvani znaju sta to znaci i kako pozivalac da generise a pozvani da proveri da li je validno i KO je predstavljen tim blobom to moze da radi. Sa razlicitim stepenom "we screwed this up" rizika
Mozes da napravis da tvoja aplikacija jednostavno posalje SID trenutno ulogovanog usera (npr Authorization: SID windowssid header) i onda na gRPC serveru imas authentication middleware koji uzme sid iz hedera i ucita tog usera iz AD i upuca ga u identity sesije i kad poziv stigne u gRPC metod user je vec namesten; headeri su encrypted i niko ne moze da vidi. naravno, to isto znaci da neki haker ako zna SID usera moze da obavi poziv umesto njega i da je jedini nacin da ga zaustavis da iskljucis usera jer je sid permanent. Sve je stvar kompromisa sta vam je vazno i od cega ste u opasnosti. Ako je ovo interna aplikacija unutar firme, onda mozes i da razmislis o ovakvim varijantama.
Imas na netu primere kako se prave asp.net core middleware komponente, sa posebnim fokusom na authorization. Trebace vam malo getting-used-to za .net core, stvari su poprilicno drugacije nego sto su bile na frameworku, ali imho, vredi uloziti trud.

---

A sad nesto sasvim drugacije. Zasto uopste gRPC?

Da ja hocu da zadrzim http1.1 da bi mogao da koristim Windows Authentication, ja bih API uradio ne u gRPCu vec kao Asp.net core API. Da, po defaultu koristi glupi JSON, ali formatter moze da se menja i da se umesto JSONa stavi XML, cime ces komunikaciju svesti na ono sto sad imas sa WCFom, verovatno i malo optimizovanije i brze. npr vidi ovde: Use XML Format With ASP.NET Core Web APIs. Ovo je za stariju verziju core-a ali princip je isti.

Na server strani ukljucis negotiate u middleware, kao ovde: Configure Windows Authentication in ASP.NET Core i bog te veselio

Na application strani moras da napravis proxy ili da manuelno pozivas URL zahteve kroz HttpClient. ja bih ti preoprucio resenje tipa Swagger jer ti automatizuje stvari dosta (na serveru generise metadata dokument, na aplikaciji taj metadata pretaba u proxy klase) pa se pozivanje svodi na pozivanje proxy klase kao sto WCF to radi. Ti bi svejedno i sa gRPC ovo morao da radis kroz protobuf fajlove. Nema vise dobrog starog automatski generisanog WSDLa

gRPC nije idealna zamena za WCF, bas zato sto ne podrzava http/2 a gomila windows LoB aplikacija koristi integrisanu domensku authentikaciju. Razlog je sto je gRPC napravio Google i kao clooud kompaniju boli ih uvo sto ti ne mozes da ga pozoves jednostavno iz thick client aplikacije, njihov goal je da gRPC bude sto brzi u kontekstu globalnih web poziva. Microsofta takodje zabole jer i oni hoce da ti uvaljaju svoj cloud i zele da ti sto vise otezaju klasicno poslovanje da bi se navuko na njihov Azure k'o budala na samar. Your business continuity? Not our problem. Tako da ti popricaj opet sa svojima i ne zalecite se previse u gRPC i http/2 generalno ako radite interne client/server aplikacije.

---

Pre svega hvala vam na odgovorima, ozbiljnog materijala ima ovde :) Sad vidim da sam trebao da otkrijem jos malo detalja oko same aplikacije i arhitekture, valjda sam se uplasio da ne zakomplikujem previse.

U pitanju je aplikacija koja se kompletno od frontenda do mssql baze hostuje na internim windows serverima. U aplikaciju se loguje preko SSO MyID sto je najnoviji update na kome sam i ja nedavno radio. Nakon toga, izmedju samih servisa se koristi Kerberos, a iz requesta na servisu se izvlaci GID koji se matchuje sa parovima instanca-GID cime se vrsi autorizacija. Sada se dodaje novi modul u aplikaciju koji treba da komunicira sa nekim bankovnim API u real time-u i za to se, analogno dosadasnjim modulima, kreira novi middleware servis koji sa jedne zove glavna aplikacija, a sa druge strane komunicira sa API-om banke xy. Prva opcija je da se nista ne eksperimentise i da se vozi po starom, znaci framework 4.8 i WCF servis. Medjutim, klijent je izrazio zelju da se ovo iskoristi kao eksperimentalni projekat i da se isproba resenje sa .NET 6 pa ako uspe da se ustanovi nova praksa za buduce projekte i potencijalno prepisivanje postojecih. Meni je tako dodeljen task da istrazim koje su alternative WCF-u pa sam dosao do gRrpc-ja nakon sto sam zakljucio da WCF Core nije prva preporucena solucija. Pored autentifikacije, bitne stavke koje sam trebao da proverim su i globalni exception handling, mogucnost da gRpc klijent bude na framework-u 4.8 itd, ali to je sve zadovoljilo minimum kriterijuma. Medjutim, kada sam pokazao POC, arhitekti se nedostatak Kerberos podrske nimalo nije svidelo tjst cinjenica da mora da se koristi autentifikacija gde u pricu ulaze cuvanje kljuceva, simetricni/asimetricni algoritmi i sl. Mislim da problem ovde nije sigurnosne prirode vec samo odrzavanje tih dodatnih kljuceva jer koliko sam shvatio oni se razlikuju od instance do instance, a mi imamo gomile instanci pa je sve to nepotreban overkill, pre svega sto toga nije bilo sa WCF-om. Sobzirom da je u pitanju visoko osetljiva aplikacija pa i sam taj novi modul, sve to ce pre pustanja u produkciju da bude izlozeno pentest maltretiranju, ne dolazi u ozbir da se ostavi bez ikakve autentifikacije.

E sad, Asp.net core API. Ovo je i meni palo na pamet jer sam nasao da podrzava Windows auth samo sto nisam znao za ove detalje tima Swagger i XML, mislio sam da smo osudjeni na raw JSON. Bas cu sad da probam kako ovo radi. Sve vise mi se cini da gRpc nije najbolji alat za ovaj posao.

Za Swagger/OpenAPI imas dva kompletna toolchaina, Swashbuckle i NSwag (ja licno koristim NSwag, ali mislim da neces pogresiti sta god da uzmes).

Imas podrsku i za Swagger UI, sto je veoma dobar nacin za testiranje APIa u development fazi:



Najbolje kreni odavde sa edukacijom: ASP.NET Core web API documentation with Swagger / OpenAPI

---

Ok, samo da rascistimo ovde, iako neces koristiti da zans za ubuduce, postoji jedan i samo jedan par kljuceva, i privatni kljuc tog para je samo na jednoj masini, na identity serveru (server koji izdaje tokene). To je sve, nema drugih kljuceva. Kao sto rekoh to nisu SSL certovi koje moras da kontinuirano osvezavas, long term self-signed cert radi posao. Ne moras cak ni da ga cuvas, ako se izgubi ili osteti, samo stavi novi, generisi ga na licu mesta ako treba. To ce efektivno "izlogovati" sve ulogovane korisnike jer ce svi JWT token potpisani starim kljucem psotati invalid, ali ce se nakon ponovnog logovanja sve vratiti na mesto. Mnogo ljudi identifikuje ovaj RSA par sa web SSL certifikatom, sem sto se pakuje u PFX i sluzi za asimtetricne kripto operacije, svaka dalja slicnost se zavrsava, JWT security se ne bazira na CA infrastrukturi. Ako je vas softver isntaliran na X mesta i na svakom treba da bude nezavistan identity server, napravis na svakom poseban PFX koji istice za 20 godina i zaboravis ga.

Klijent koji hoce da proveri token skida public key sa identity servera koji je u JWT issuer polju, i na tome se bazira security, ne na nekom nezavisnom certificate authorty-u koji ti je dao jednogodisnji SSL cert. JWT kaze "mene je izdao ovaj identity server, uzmi njegov public key da me proveris, ako verujes tom serveru kao autoritetu, veruj i meni da predstavljam ovog end usera". To je sve. Obicno se preporucuje da se public key kesira 24h da se ne bi tuklo po identity serveru. Za asp.net i .net core, taj posao je vec odradjen kao deo Jwt authorization biblioteke. kad u middlware registrujes authorization komponentu sa .AddJwtBearer(), ta komponenta ce autoamtski detektovati Authorization Bearer header, izvuci token, parsirati ga, validirati (ako je RSA i nema kesiran public key skinuce ga), povezace subject na identity i popuniti identity claims. Sve potpuno transparentno, kad kod udje u tvoj API metod, identity je vec spreman i validiran.

---

Hvala mmix. Uspeo sam da prepisem ovaj POC da koristi Core api i windows auth. Proxy klase sam generisao sa NSwag Studio, ne znam da li je to preferirani nacin, ali je profunkcionisalo. Uspeo sam da namestim i da koristi XML umesto JSON-a za razmenu. Namestio sam i global exception handling, po meni znatno sofisticiranije deluje nego resenje sa interceptorima u gRpc. Videcemo sta kaze tim, ali ja licno se ne bih vise bavio gRpc-om sobzirom da ova varijanta sa core api radi sve sto nam treba.

Sve gore navedeno stoji ali definitivno nije najbrzi nacin komunikacije...
gRPC je vrh kad klijenti nisu web, prvo nenormalno je brz i nikakav REST API ne moze da mu pridje ni blizu jer ni JSON ni XML nemaju bas tako mali footprint, iz proto mozes da generises klase isto ko iz wsdl, ima dvosmernu komunikaciju (push) tako da pratis klijente 100%, svaki techstack koji drzi do sebe vec ima napravljene tools za generisanje klasa iz proto, etc ..
U svakom slucaju u tom scenariju gRPC i JWT bi bili moj izbor definitivno ...
REST kod mene radi samo kad su externi klijenti raznih vrsta upleteni inace za internu upotrebu WebSockets za web i gRPC za ne web klijente...
Just my 2c :)

---

JWT je po definiciji JSON Web Token tako da "gRPC je vrh kad klijenti nisu web" je nekako neodgovarajuce po definiciji U sta se tdusko i licno uverio

gRPC jeste brzi jer radi binary serijalizaciju i ne mora da otvara nove konekcije za vise poziva (mada to je resivo sa http1/1 kroz kesiranje), ali nije prilagodjen windows domain klijentima. Ako si bas dokon mozes i sam da pakujes objekte u binary i da implementiras svoj encode/decode middlware, ali ko ce s tim da se zeza. Narocito kad imas situaciju da je sve to lepo vec sljakalo sa XML/WCFom, tako da data volume i speed nije problem.
Cinjenica da MS zabole za to ima vise sa tim sto hoce da ti prodaju Azure nego sto to nije izvodljivo. Nerealno je ocekivati od korporativnih korisnika da se dva puta loguju da bi mogli da koriste tvoju aplikaciju. Iskreno, svacega sam se nagledao kao workaround za to, a najjaci su mi fake JWT token authentication web endpointi (tipa ovoga https://jasonwatmore.com/post/...tion-tutorial-with-example-api) koji prepakuju negotiated http1/1 poziv u HMAC signed JWT token pa se kompletna security infastruktura zasniva na deljenoj "tajni" koja je redovno upakovana u appSettings.json. Sve to radi zalepljeno flasterima samo zato sto se niko nije bas ni malo potrudio da ga provali, tako da mozes komotno i da iskljucis authentication za gRPC i da verujes svakom ko te pozove.

Samo zato sto je nesto izvodljivo, ne znaci da je sigurno.

---

OK OK napisao sam samo sta ja radim u bas takvim situacijama i zasto, znaci WCF menjam sa gRPC, a WCF Data Services za REST/OData ..
Ovo ostalo bas nisam razumeo ali nisam mislio na nista slicno ...
Jedno se ne slazem da Web u JWT znaci da je samo za web vec i za web posto je json pa js to native koristi (koristim web client za js client sto nije bas tacno ali eto)

---

U medjuvremenu smo zapoceli novi projekat sa Core API-Swagger. Za sad mi solidno ide, svasta nesto sam uspeo mada ima izazova na svakom koraku sobzirom da smo u WCF implementaciji imali dosta customizacija oko samog generisanja proxy klasa pa sad jedno po jedno implementiram u novom projektu. Za automatsko generisanje i osvezavanje proxy klasa sam napravio TT skriptu koja sklapa Service URL i poziva nswag.cmd sa parametrima. Tu imam konkretni izazov koji ne uspevam da resim. Naime, u WCF-u nam je konfigurisano tako da kada se Proxy klase generisu, u SvcUtilTls12.exe se salje u parametru /reference lista namespace-ova. Generisani fajl sa proxy klasama nece sadrzati definicije klase iz ovih namespace-ova, a tamo gde su te klase referencirane stajace kompletno ime klase sa sve namespace-om. Razlog za ovakvo generisanje je to sto je Projekat DLL gde su DTO klase referenciran i na klijentu i na serveru. Ovakvo ponasanje ne uspevam da repliciram sa Swagger-om. Ono sto sam uspeo jeste da mu posaljem tipove cije definicije ne zelim da vidim u generisanim proxy klasama, sto je super. Medjutim, ne uspevam da mu objasnim da na te klase nakaci namespace-ove kao prefix. Alternativa je da umesto toga imam listu usinga na pocetku fajla sto sam isto uspeo da mu posaljem kao parametar, ali su mi rekli da je to ok, ali da je prva opcija preferirana.

Znaci ako je na serveru





Proxy klasa treba da izgleda ovako:


Zna li neko jel ovo moguce postici? Ima li uopste (makar i u teoriji) rizika ako umesto ovoga imam na pocetku proxy fajla: using Server.Models ? Hvala

Samo mala ispravka: WCF je podrzan u dotNet 6.0.
Ako aplikaciju prepisujes u novu tehnologiju mozes ga koristi isto kao i u prosloj.
Naknadno su ga dodali verovatno usled pritiska zajednice jer dobar deo integracija je jos uvek na SOAP-u

Mada ako vec menjas celu arhitekturu nije lose da se oslobodis WCF-a.