Verbinding van Clients achter firewall naar Server

[Lethalis]

Modbreak:

Reacties afgesplitst vanuit topic De Devschuur Coffee Corner - Iteratie ⓬

Even een domme vraag, maar wat is een goede oplossing om een service te exposen achter een firewall waar je geen controle over hebt?

In principe wil je dat jouw applicatie dan zelf een verbinding maakt met de server, en dat de server dan commando's hierover kan terug sturen. Ik vraag me alleen af of hiervoor iets kant en klaars is (voor .NET). Zijn message queuing libraries hiervoor eventueel geschikt?

Er zal ook iets qua fault tolerance in moeten zitten en het moet natuurlijk via SSL werken.

Ik zit namelijk met 500+ on premises installaties van onze software en we willen een nieuwe portal maken die ermee kan praten Alleen hebben wij dus geen controle over de infrastructuur en is het voor ons dus niet te doen om ports open te gaan zetten etc.

En het moet dermate snel werken dat polling geen optie is.

PS
In theorie kan ik me voorstellen dat ze allemaal als client met een Message Queueing server (of iets dergelijks) verbinden en dus berichten kunnen ontvangen en versturen. Ik vind e.e.a. over AMQP en dat soort dingen, maar geen idee of ik daarmee op de goede weg ben. En wat handig werkt met .NET (goede libraries heeft etc).

[ Voor 19% gewijzigd door Woy op 12-04-2019 10:52 ]

[TheNephilim]

Lethalis schreef op woensdag 10 april 2019 @ 16:48:
Even een domme vraag, maar wat is een goede oplossing om een service te exposen achter een firewall waar je geen controle over hebt?

In principe wil je dat jouw applicatie dan zelf een verbinding maakt met de server, en dat de server dan commando's hierover kan terug sturen. Ik vraag me alleen af of hiervoor iets kant en klaars is (voor .NET). Zijn message queuing libraries hiervoor eventueel geschikt?

Er zal ook iets qua fault tolerance in moeten zitten en het moet natuurlijk via SSL werken.

Ik zit namelijk met 500+ on premises installaties van onze software en we willen een nieuwe portal maken die ermee kan praten Alleen hebben wij dus geen controle over de infrastructuur en is het voor ons dus niet te doen om ports open te gaan zetten etc.

En het moet dermate snel werken dat polling geen optie is.

PS
In theorie kan ik me voorstellen dat ze allemaal als client met een Message Queueing server (of iets dergelijks) verbinden en dus berichten kunnen ontvangen en versturen. Ik vind e.e.a. over AMQP en dat soort dingen, maar geen idee of ik daarmee op de goede weg ben. En wat handig werkt met .NET (goede libraries heeft etc).

Heb je de mogelijkheid om over een standaard poort te praten? Bijv 443 ofzo?

[mcDavid]

Lethalis schreef op woensdag 10 april 2019 @ 16:48:
Even een domme vraag, maar wat is een goede oplossing om een service te exposen achter een firewall waar je geen controle over hebt?

In principe wil je dat jouw applicatie dan zelf een verbinding maakt met de server, en dat de server dan commando's hierover kan terug sturen. Ik vraag me alleen af of hiervoor iets kant en klaars is (voor .NET). Zijn message queuing libraries hiervoor eventueel geschikt?

Er zal ook iets qua fault tolerance in moeten zitten en het moet natuurlijk via SSL werken.

Ik zit namelijk met 500+ on premises installaties van onze software en we willen een nieuwe portal maken die ermee kan praten Alleen hebben wij dus geen controle over de infrastructuur en is het voor ons dus niet te doen om ports open te gaan zetten etc.

En het moet dermate snel werken dat polling geen optie is.

PS
In theorie kan ik me voorstellen dat ze allemaal als client met een Message Queueing server (of iets dergelijks) verbinden en dus berichten kunnen ontvangen en versturen. Ik vind e.e.a. over AMQP en dat soort dingen, maar geen idee of ik daarmee op de goede weg ben. En wat handig werkt met .NET (goede libraries heeft etc).

In principe moet je dat natuurlijk in de eerste plaats niet willen. Die firewall zal er niet voor niets zijn. Zorg maar dat de beheerder van dat netwerk weet wat je doet en de benodigde poorten open zet. De keuze dat wel of niet te doen is aan hem.

Of zorg dat je op een eigen netwerk (VPN) zit waar je zelf de controle over hebt en wat volledig gescheiden is van dat netwerk van de 3e partij.

[Mugwump]

Message queuing werkt vanuit het perspectief van een firewall niet anders dan bijvoorbeeld communicatie met een http server.

Als ik de vraag goed begrijp dan wil je iets blootstellen wat in een netwerk achter een firewall draait. Het hele idee van een firewall is dat dit niet zomaar kan.

Waar messaging afwijkt van bijvoorbeeld synchrone communicatie via een REST API is dat je berichten op een queue zet en de consumerende kant zelf kan bepalen wanneer die opgepakt worden (en je als verzendende partij in de basis ook geen idee hebt van wanneer dat gebeurt).

[Lethalis]

mcDavid schreef op woensdag 10 april 2019 @ 17:26:
[...]


In principe moet je dat natuurlijk in de eerste plaats niet willen. Die firewall zal er niet voor niets zijn. Zorg maar dat de beheerder van dat netwerk weet wat je doet en de benodigde poorten open zet. De keuze dat wel of niet te doen is aan hem.

Of zorg dat je op een eigen netwerk (VPN) zit waar je zelf de controle over hebt en wat volledig gescheiden is van dat netwerk van de 3e partij.

Je maakt de denkfout dat bij onze klanten (voor dit product) een beheerder zit

Dit gaat om kleine bedrijven met een standaard router van hun provider. Vaak weten ze amper de inloggegevens van hun mail, laat staan dat ze een VPN opzetten of een router configureren.

Dus ik zit aan bidirectionele sockets te denken etc en hoop op iets mooiers.

Andere optie wordt dat het niet realtime is, maar dat we informatie gaan uploaden, bufferen en syncen met alle ellende vandien. Voor bepaalde functionaliteiten zou het misschien nog kunnen, zal ik per functie moeten bekijken.

[ Voor 11% gewijzigd door Lethalis op 10-04-2019 20:03 ]

[gekkie]

Vanaf welke kant wil je de connectie initieel opzetten ?
Lijkt er op dat je dat wilt vanuit jullie naar binnen bij het netwerk van de klant ?
(anders zie ik het probleem namelijk niet zo)

[Lethalis]

gekkie schreef op woensdag 10 april 2019 @ 20:07:
Vanaf welke kant wil je de connectie initieel opzetten ?
Lijkt er op dat je dat wilt vanuit jullie naar binnen bij het netwerk van de klant ?
(anders zie ik het probleem namelijk niet zo)

Er draait software van ons bij de klant, dus die mag en kan initieel de verbinding opzetten.

Vervolgens willen we dan alleen wel vanaf onze kant requests doen op informatie die bij de klant staat over diezelfde verbinding.

Dit uiteraard allemaal met goedkeuring en in opdracht van de klant, alleen moet het technisch gezien dus low maintenance zijn en gewoon achter een firewall kunnen werken.

Idee is dat de klant bij ons inlogt op een portaal die in verbinding staat met zijn lokale installatie. En zo dus ook vanaf thuis en ook andere locaties erbij kan (voor specifieke toepassingen).

[gekkie]

Lethalis schreef op woensdag 10 april 2019 @ 20:14:
[...]

Er draait software van ons bij de klant, dus die mag en kan initieel de verbinding opzetten.

Vervolgens willen we dan alleen wel vanaf onze kant requests doen op informatie die bij de klant staat over diezelfde verbinding.

Dit uiteraard allemaal met goedkeuring en in opdracht van de klant, alleen moet het technisch gezien dus low maintenance zijn en gewoon achter een firewall kunnen werken.

Idee is dat de klant bij ons inlogt op een portaal die in verbinding staat met zijn lokale installatie. En zo dus ook vanaf thuis en ook andere locaties erbij kan (voor specifieke toepassingen).

Hmmm owhkee ..
maar dan is het dus een soort cloud service die niet in de cloud mag en dus lokaal staat maar wel volledig van jullie uit benaderbaar is ?

[ Voor 13% gewijzigd door gekkie op 10-04-2019 20:19 ]

[Alex)]

De applicatie die je bij je klanten zet bouwt een verbinding op met jullie server en houdt die open, zodat jullie server weer requests kan sturen naar de client. De client is dan verantwoordelijk voor het opzetten en openhouden van de verbinding.

Een IRC-client doet eigenlijk niet veel anders dan dat.

[ Voor 14% gewijzigd door Alex) op 10-04-2019 20:20 ]

[EddoH]

Alex) schreef op woensdag 10 april 2019 @ 20:19:
De applicatie die je bij je klanten zet bouwt een verbinding op met jullie server en houdt die open, zodat jullie server weer requests kan sturen naar de client. De client is dan verantwoordelijk voor het opzetten en openhouden van de verbinding.

Een IRC-client doet eigenlijk niet veel anders dan dat.

Niet eens hole-punching, gewoon een cliënt server verbinding. Hole punching gebruik je om een peer-peer connectie tot stand te brengen via een server.

Blah blah blah

[.oisyn]

EddoH schreef op woensdag 10 april 2019 @ 20:21:
[...]


Niet eens hole-punching, gewoon een cliënt server verbinding. Hole punching gebruik je om een peer-peer connectie tot stand te brengen via een server.

Zoals je kan zien had ie dat al gewijzigd voor jij op quote drukte

[Alex)]

Standaard client-server inderdaad. Daarom had ik de hole punching-opmerking al weggehaald

[Douweegbertje]

Lethalis schreef op woensdag 10 april 2019 @ 16:48:
Even een domme vraag, maar wat is een goede oplossing om een service te exposen achter een firewall waar je geen controle over hebt?

In principe wil je dat jouw applicatie dan zelf een verbinding maakt met de server, en dat de server dan commando's hierover kan terug sturen. Ik vraag me alleen af of hiervoor iets kant en klaars is (voor .NET). Zijn message queuing libraries hiervoor eventueel geschikt?

Er zal ook iets qua fault tolerance in moeten zitten en het moet natuurlijk via SSL werken.

Ik zit namelijk met 500+ on premises installaties van onze software en we willen een nieuwe portal maken die ermee kan praten Alleen hebben wij dus geen controle over de infrastructuur en is het voor ons dus niet te doen om ports open te gaan zetten etc.

En het moet dermate snel werken dat polling geen optie is.

PS
In theorie kan ik me voorstellen dat ze allemaal als client met een Message Queueing server (of iets dergelijks) verbinden en dus berichten kunnen ontvangen en versturen. Ik vind e.e.a. over AMQP en dat soort dingen, maar geen idee of ik daarmee op de goede weg ben. En wat handig werkt met .NET (goede libraries heeft etc).

Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.

[EddoH]

Alex) schreef op woensdag 10 april 2019 @ 20:22:
Standaard client-server inderdaad. Daarom had ik de hole punching-opmerking al weggehaald

Ja gvd, doe dat volgende keer eens ff nadat ik op quote druk

[Lethalis]

Douweegbertje schreef op woensdag 10 april 2019 @ 20:22:
[...]


Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.

Ja I know, maar ik wil niet voor elke scheet een topic aanmaken Dus soms gooi ik hier ff iets in de groep.

Meestal puur voor wat pointers, rest doe ik zelf wel.

gekkie schreef op woensdag 10 april 2019 @ 20:18:
[...]

Hmmm owhkee ..
maar dan is het dus een soort cloud service die niet in de cloud mag en dus lokaal staat maar wel volledig van jullie uit benaderbaar is ?

Zoiets It's a mad world

Het is antiek vs de moderne wereld.

[ Voor 27% gewijzigd door Lethalis op 10-04-2019 20:44 ]

[EddoH]

Lethalis schreef op woensdag 10 april 2019 @ 20:42:
[...]

Ja I know, maar ik wil niet voor elke scheet een topic aanmaken Dus soms gooi ik hier ff iets in de groep.

Meestal puur voor wat pointers, rest doe ik zelf wel.


[...]

Zoiets It's a mad world

Het is antiek vs de moderne wereld.

Wellicht nog een simpele oplossing als je niets aan de software zelf wil veranderen: een reverse ssh tunnel.

[gekkie]

EddoH schreef op woensdag 10 april 2019 @ 20:51:
[...]


Wellicht nog een simpele oplossing als je niets aan de software zelf wil veranderen: een reverse ssh tunnel.

Ooit wel gebruikt voor semi-mobiele-appliance servertjes als manier om in geval van nood op die dingen te kunnen inloggen. Klant plugt usb-stickje in met tekst-bestandje met phonehome commando.
Ding ssh't naar server .. en vervolgens kon ik met reverse ssh vrolijk kijken wat er loos was en beperkte updates uitvoeren. Aangezien ding headless was, mocht tie fijn alle stadia met TTS uit brabbelen.

Maarja dat was wel handmatig geinitieerd .. en hoefde ook niet "always on" te zijn.

Lijkt me in het onderhavige geval een beetje frusterend als je in die portal steeds te zien krijgt dat je toko niet bereikbaar is en totdat er bij je eigen toko lokaal ergens tegenaan geschopt wordt je het ook kan vergeten.

[ Voor 19% gewijzigd door gekkie op 10-04-2019 21:28 ]

[EddoH]

gekkie schreef op woensdag 10 april 2019 @ 21:26:
[...]
Lijkt me in het onderhavige geval een beetje frusterend als je in die portal steeds te zien krijgt dat je toko niet bereikbaar is en totdat er bij je eigen toko lokaal ergens tegenaan geschopt wordt je het ook kan vergeten.

Kan je natuurlijk heel makkelijk in een service/cronjob/whatever-fits-your-needs stoppen

[F.West98]

@Lethalis Misschien iets met websockets? Heeft prima .NET support, zelf ook wel eens mee gewerkt: https://docs.microsoft.co...ckets?view=aspnetcore-2.2

(alleen geen idee of je ook buiten een browser om makkelijk zo'n ding kan aanmaken, maar het is wel mooi gestandaardiseerd enzo)

[ Voor 25% gewijzigd door F.West98 op 10-04-2019 22:57 ]

[Woy]

Lethalis schreef op woensdag 10 april 2019 @ 16:48:
In principe wil je dat jouw applicatie dan zelf een verbinding maakt met de server, en dat de server dan commando's hierover kan terug sturen. Ik vraag me alleen af of hiervoor iets kant en klaars is (voor .NET). Zijn message queuing libraries hiervoor eventueel geschikt?

Het is nogal afhankelijk van wat je precies wil, je kunt denken aan iets web-socket gebaseerd, AMQP, MQTT, iets zelf met een TCP socket, of de legio andere oplossingen

Voor een eigen IoT project maak ik gebruik van MQTT, maar dat is vooral omdat het light-weight moet zijn omdat er ook embedded clients verbinden. Bij een desktop client heb je weer andere overwegingen die je mee wil nemen.

[ Voor 16% gewijzigd door Woy op 10-04-2019 23:04 ]

[xh3adshotx]

Lethalis schreef op woensdag 10 april 2019 @ 16:48:
Even een domme vraag, maar wat is een goede oplossing om een service te exposen achter een firewall waar je geen controle over hebt?

In principe wil je dat jouw applicatie dan zelf een verbinding maakt met de server, en dat de server dan commando's hierover kan terug sturen. Ik vraag me alleen af of hiervoor iets kant en klaars is (voor .NET). Zijn message queuing libraries hiervoor eventueel geschikt?

Er zal ook iets qua fault tolerance in moeten zitten en het moet natuurlijk via SSL werken.

Ik zit namelijk met 500+ on premises installaties van onze software en we willen een nieuwe portal maken die ermee kan praten Alleen hebben wij dus geen controle over de infrastructuur en is het voor ons dus niet te doen om ports open te gaan zetten etc.

En het moet dermate snel werken dat polling geen optie is.

PS
In theorie kan ik me voorstellen dat ze allemaal als client met een Message Queueing server (of iets dergelijks) verbinden en dus berichten kunnen ontvangen en versturen. Ik vind e.e.a. over AMQP en dat soort dingen, maar geen idee of ik daarmee op de goede weg ben. En wat handig werkt met .NET (goede libraries heeft etc).

SignalR (core) lijkt mij een prima oplossing. Prima integratie met .net, zowel server als client-side en best flexibel. Let wel op dat de .net framework server/client niet met .net core server/client kan verbinden.

[Sandor_Clegane]

Lethalis schreef op woensdag 10 april 2019 @ 16:48:
Snip

Websockets. Zijn bidirectioneel en gaan over de algemene firewall omzeil poort. ( 80 en 443 )

Websocketsharp is leuke library.

[Lethalis]

Bedankt voor de suggesties!

Ik zal een test opzetten met WebSockets.

[ZaZ]

In mijn optiek moet je gewoon software schrijven zoals het zou moeten werken in de ideale wereld.
Nu ga je zelf iets verzinnen om om de firewall heen te gaan. Allemaal regels en logica die waarschijnlijk totaal niet in de software thuishoren en misschien introduceer je wel erge zwakheden.
Ik begrijp dat het heel makkelijk is om te roepen "dan moeten ze de firewall maar openzetten" en ik weet dat dat lang niet altijd gaat. Maar kan je dan niet gewoon een gat door de firewall meppen met een SSH of iets dergelijks? Gewoon aan jullie kant een servertje, in jullie firewall een poort open voor ip van klant, private/public key en een port mapping.
Dan kan de service app bij de klant gewoon werken zoals je eigenlijk wilt dat ie werkt en connect jij op jullie server.
Zo doet elke laag waar ie goed in is.

[Lethalis]

ZaZ schreef op donderdag 11 april 2019 @ 01:57:
In mijn optiek moet je gewoon software schrijven zoals het zou moeten werken in de ideale wereld.
Nu ga je zelf iets verzinnen om om de firewall heen te gaan. Allemaal regels en logica die waarschijnlijk totaal niet in de software thuishoren en misschien introduceer je wel erge zwakheden.

In principe ben ik het met jou eens, vooral wat de beveiliging betreft. WebSockets houden zich bijvoorbeeld niet aan cors, waardoor iemand ze zou kunnen hijacken als je je daar niet bewust van bent.

Daarom zou ik ook elke request voorzien van een session token die verloopt. En alle gegevens mbt de authenticatie bij de klant houden. De portal zou puur een doorgeefluik zijn.

Het probleem met SSH of een VPN server oplossing is dat ik hierbij bang ben dat wij er tijd aan kwijt gaan raken qua beheer en dat je je dan serieus moet afvragen of dat het wel waard is (vanwege de 500+ klanten).

De oplossing moet zoveel mogelijk "automagisch" werken. Oftewel: de klant installeert de update die hij van ons krijgt en vanaf dat moment is het een vinkje in ons pakket om het aan te zetten. En niet meer dan dat.

Onze updates zijn ook grotendeels automatisch. Klant krijgt een popup en drukt op OK.

Onze software wordt veel gebruikt door "de vrouw van de baas" die de administratie van deze klanten doet.

Kortom, als jouw moeder het niet kan installeren dan is het te complex

Maar goed, ik ben puur aan het researchen momenteel.

Groot nadeel wat ik kan bedenken van een socketverbinding is bijvoorbeeld dat je er al meerdere van nodig hebt, omdat de portal anders op elke request moet wachten.

En zo werkt een webapplicatie normaal gesproken niet. Als ik iets met Angular bouw, dan probeer ik vaak zoveel mogelijk requests simultaan uit te voeren vanwege de performance.

Zou ik gewoon bij een rest api kunnen bij de klant zou dat geen enkel probleem zijn.

Ik ga sowieso nog met onze service desk in gesprek hoe zij ertegenaan kijken.

[Sandor_Clegane]

Ach, als jij degene bent die de verbinding initieert, vanuit software die je zelf hebt geschreven naar eigen servers dan kun je je nog afvragen hoe groot de attack surface is.

[hackerhater]

Met SSH is het probleem niet.
Je kan aan de kant van de client het zo instellen dat ie zelf de connectie opent en hem hersteld als ie x minuten down is.
At least zoiets heb ik een keer met Linux gedaan, maar ongetwijfeld kan dat met Windows ook.
Dat was een VPN naar een remote beheer club

[ Voor 8% gewijzigd door hackerhater op 11-04-2019 08:39 ]

[xh3adshotx]

Lethalis schreef op donderdag 11 april 2019 @ 07:24:
[...]

Groot nadeel wat ik kan bedenken van een socketverbinding is bijvoorbeeld dat je er al meerdere van nodig hebt, omdat de portal anders op elke request moet wachten.

En zo werkt een webapplicatie normaal gesproken niet. Als ik iets met Angular bouw, dan probeer ik vaak zoveel mogelijk requests simultaan uit te voeren vanwege de performance.

Zou ik gewoon bij een rest api kunnen bij de klant zou dat geen enkel probleem zijn.

Ik ga sowieso nog met onze service desk in gesprek hoe zij ertegenaan kijken.

Over een socket verbinding kan je in principe wel meerdere "requests" doen maar dat is natuurlijk wel wat complexer. Mede daardoor stelde ik SignalR core voor waar dat voor je gedaan is. Aan beide kanten heb je een "hub" en kan je gewoon methods invoken alsof het lokale methods zijn, SignalR regelt de concurrency voor je. Uiteindelijk gebruikt SignalR gewoon websockets met een fallback naar long-polling etc.

[Lethalis]

xh3adshotx schreef op donderdag 11 april 2019 @ 09:09:
[...]
Over een socket verbinding kan je in principe wel meerdere "requests" doen maar dat is natuurlijk wel wat complexer. Mede daardoor stelde ik SignalR core voor waar dat voor je gedaan is. Aan beide kanten heb je een "hub" en kan je gewoon methods invoken alsof het lokale methods zijn, SignalR regelt de concurrency voor je. Uiteindelijk gebruikt SignalR gewoon websockets met een fallback naar long-polling etc.

Ik zal ook SignalR eens goed bekijken

[Douweegbertje]

Of https://nats.io/ of https://kafka.apache.org/

[Gropah]

kafka is wel echt een beetje overkill though voor de meeste applicatie's. Dat word pas interessant bij een bepaald volume aan berichten wat je wilt verwerken.

[Hydra]

Gropah schreef op vrijdag 12 april 2019 @ 08:30:
kafka is wel echt een beetje overkill though voor de meeste applicatie's. Dat word pas interessant bij een bepaald volume aan berichten wat je wilt verwerken.

Komt ook nog eens bij dat het best complex is. Je zet niet 'even' een kafka cluster / architectuur neer. De garanties die Kafka geeft kwa volgorde zijn bijvoorbeeld wel binnen een partitie bijvoorbeeld, dus je moet echt opletten waarop je partitioneert.

[Woy]

Lethalis schreef op woensdag 10 april 2019 @ 20:42:
[...]
Ja I know, maar ik wil niet voor elke scheet een topic aanmaken Dus soms gooi ik hier ff iets in de groep.

Wat mij betreft is het toch wel een idee om gewoon een topic te maken, dan hoeven wij niet weer te gaan verplaatsen

[Lethalis]

Sandor_Clegane schreef op donderdag 11 april 2019 @ 08:37:
Ach, als jij degene bent die de verbinding initieert, vanuit software die je zelf hebt geschreven naar eigen servers dan kun je je nog afvragen hoe groot de attack surface is.

Better safe than sorry

Het laatste dat je wil, is dat iemand in staat is om gegevens van een andere klant op te vragen. Dus het zal wel degelijk serieus dicht getimmerd moeten worden.

Met SignalR kom ik een heel eind trouwens. Mijn eerste testproject werkt in ieder geval. Ik laat een client verbinding maken naar een hub en vervolgens roep ik een aanmeldfunctie aan waarmee de client zich identificeert, zodat ik weet bij welke ConnectionId de klant hoort.

Wil ik vanuit de portal dan een request doen naar een specifieke klant, dan kan ik simpelweg opzoeken welke connection ik daarvoor nodig heb en een request doen

Vervolgens moet ik natuurlijk nog een session token inbouwen en dergelijke, maar de eerste tests zijn hoopvol.

Dus ik denk dat ik voor SignalR ga, ook omdat het helemaal geïntegreerd is in .NET. De server opzetten was echt een fluitje van een cent met ASP.Net Core, waar SignalR simpelweg included is. En voor de client is er een simpele library.

[xh3adshotx]

Lethalis schreef op vrijdag 12 april 2019 @ 12:21:
[...]

Better safe than sorry

Het laatste dat je wil, is dat iemand in staat is om gegevens van een andere klant op te vragen. Dus het zal wel degelijk serieus dicht getimmerd moeten worden.

Met SignalR kom ik een heel eind trouwens. Mijn eerste testproject werkt in ieder geval. Ik laat een client verbinding maken naar een hub en vervolgens roep ik een aanmeldfunctie aan waarmee de client zich identificeert, zodat ik weet bij welke ConnectionId de klant hoort.

Wil ik vanuit de portal dan een request doen naar een specifieke klant, dan kan ik simpelweg opzoeken welke connection ik daarvoor nodig heb en een request doen

Vervolgens moet ik natuurlijk nog een session token inbouwen en dergelijke, maar de eerste tests zijn hoopvol.

Dus ik denk dat ik voor SignalR ga, ook omdat het helemaal geïntegreerd is in .NET. De server opzetten was echt een fluitje van een cent met ASP.Net Core, waar SignalR simpelweg included is. En voor de client is er een simpele library.

Ikzelf zou de authentication doormiddel van IdentityServer doen. Vervolgens kan je de user opzoeken aan de hand van de nameidentifier van de claim, op die manier hoef je zelf geen state bij te houden.

[laurens0619]

SignalR is prima oplossing inderdaad hiervoor en qua security zou ik gewoon de best practices volgen:
https://docs.microsoft.co.../introduction-to-security

Ik zou persoonlijk niet zelf aan de slag met sessietokens etc. Als je SSL gebruikt (icm certificate pinning/hpkp) dan gaat het niemand lukken om op de lijn op de sessie mee te liften/te herbruiken.

Verder moet je er gewoon vanuit gaan dat je de client niet vertrouwd dus alleen data laten opsturen die je valideerd en niet executables over die verbinding gaan gooien

Mocht je toch met sessietokens aan de gang willen: Denk dan eerst als een aanvaller en kijken hoe/met welk doel ze misbruik zouden kunnen maken

[Lethalis]

xh3adshotx schreef op zaterdag 13 april 2019 @ 14:32:
[...]
Ikzelf zou de authentication doormiddel van IdentityServer doen. Vervolgens kan je de user opzoeken aan de hand van de nameidentifier van de claim, op die manier hoef je zelf geen state bij te houden.

Ik hou meestal geen state bij, maar werk met JWT tokens die signed zijn met standaard libraries daarvoor.

Geen idee of het correct van mij is om dat session tokens te noemen

IdentityServer ziet er verder wel interessant uit en heeft wel wat voordelen ten opzichte van mijn standaard aanpak, dus ik ga daar t.z.t. ook eens rustig voor zitten

laurens0619 schreef op zaterdag 13 april 2019 @ 14:57:
Ik zou persoonlijk niet zelf aan de slag met sessietokens etc. Als je SSL gebruikt (icm certificate pinning/hpkp) dan gaat het niemand lukken om op de lijn op de sessie mee te liften/te herbruiken.

We hebben het hier over 2 verschillende dingen:
1. De client die zich aanmeldt op de server. Hij zet een SSL verbinding op en zegt in feite "ik ben klant X".
2. De server die zich moet authenticeren om gegevens bij de client (klant) te kunnen opvragen. Een gebruiker meldt zich op de server (portal) aan door bij de client (klant X) een token op te vragen (met een naam en wachtwoord).

Voor stap 2 wil ik dus met tokens werken, om te voorkomen dat iemand bij gegevens kan waar hij niet bij mag.

[ Voor 32% gewijzigd door Lethalis op 13-04-2019 18:06 ]