Account service, permissions + load

[Rekcor]

Ons systeem heeft een services architectuur. Centraal in dit systeem zit een account service, die vooralsnog authenticatie als authorisatie verzorgt:



Onze discussie van zojuist ging over het volgende. In de figuur hierboven wordt de gebruiker ingelogd bij service A. Het idee is dan dat service A ook weet welke rechten de gebruiker heeft.

Iemand in ons team stelde echter een andere opzet voor, namelijk dat service A niet weet welke rechten de gebruiker heeft. Bij iedere call naar service A, vraagt service A aan de accountservice 'mag user X deze call doen?'. Het voordeel is dan dat je meer controle hebt (je kunt 'live' een user rechten geven/ontnemen) en dat service A (t/m Z) niets hoeven op te slaan over de gebruiker. Het nadeel is dat account-service extra belast wordt.

Wat raden jullie aan? Welke argumenten zijn er nog meer?

[HMS]

Authenticatie en Authorizatie zijn gewoon cross cutting concerns die je met elke module weer gaat krijgen. Los je dit in 1 keer op, of ga je het probleem elke keer weer oplossen? Waarom pas je DRY (Don't Repeat Yourself) wel toe op code niveau, maar is dit op service niveau schijnbaar niet belangrijk?

Eventueel zou je de authenticatie en authorisatie kunnen splitsen zodat je dit nog afzonderlijk kan schalen (aangenomen dat het argument 'account-service extra belast' genoemd is omdat dit een probleem zou kunnen zijn).

[Rekcor]

Ok, dus jij zou voor iedere call naar service A, service A een call laten maken naar de account/authorisatie-server, om te vragen of de user deze call mag maken?

En stel er is een service B, die - namens de gebruiker - een call maakt naar service A? Krijg je dan twee checks?
1) mag user call maken naar A
2) mag user call maken naar B

Het komt mij voor dat het aantal calls naar de account/authorisatie-server erg snel exponentieel wordt.

[ Voor 47% gewijzigd door Rekcor op 18-03-2014 17:25 . Reden: uitbreiding vraag ]

[HMS]

Uiteraard kan je bepaalde dingen wel cachen aan de kant van Service A, maar dat betekent niet dat Service A verantwoordelijk is voor het regelen van de authenticatie en authorisatie.

Daarnaast, heb je een ruw idee over hoeveel calls het gaat? Hoeveel calls maken gebruik van een chain van meerdere services? Hoeveel requests kan de authorisatie service precies aan? Hoeveel load verwacht je?

Rekcor schreef op dinsdag 18 maart 2014 @ 17:03:
En stel er is een service B, die - namens de gebruiker - een call maakt naar service A? Krijg je dan twee checks?
1) mag user call maken naar A
2) mag user call maken naar B

Nee, met de aanname dat een call naar A nodig is om een call naar B goed af te handelen. Het is dan impliciet dat als een call naar B mag, dan mag een call naar A ook. Want zonder de call naar A kan je de call naar B niet goed afhandelen. Let wel, je wil eigenlijk zo min mogelijk impliciete dingen in je authorisatie hebben.

Daarnaast is het nogal vreemd dat service B (die in principe autonoom zou moeten functioneren als je een beetje goed SOA doet) zo'n sterke dependency heeft op service A.

edit: Dat de meeste services een dependency hebben op de authenticatie en authorisatie komt omdat dat een cross cutting concern is voor alle services, dus dat zal onderdeel moeten zijn van je applicatie infrastructuur.

[ Voor 8% gewijzigd door HMS op 18-03-2014 17:40 ]

[Rekcor]

Dank!

Service B kan ook direct benaderd worden door de user - en dan moet wel degelijk de check uitgevoerd worden - maar (natuurlijk) ook door andere services.

Vooralsnog beperkt e.e.a. zich tot tientallen request per minuut. Dit kan echter in de toekomst oplopen, en dan wil ik e.e.a. zo schaalbaar mogelijk opgezet hebben.