AppService na azure i klienci desktopowi - jak udostępnić ?

Hej, mam pytanko, gdyż wystawiam swoją pierwszą appke na Azure. Appka napisana w ASP.NET Core, jest to usługa REST. Wystawiłem ją jako AppService w Azurze. W networking w ustawieniach dodałem swoje IP w firewall i dzięki temu mogę zapewne strzelać sobie do niej lokalnie z postmana.

Jednak teraz chcę by inni klienci mogli się integrować z tym api. Rozumiem, że gdyby klientem była appka webowa, która też byłaby gdzieś wystawiona wystarczyło by do reguł firewalla dodać po prostu IP tej appki bo klienci za jej pośrednictwem korzystali by z mojego API.

Jak natomiast wygląda sytuacja w przypadku klientów desktopowych? W tym przypadku client nie będzie nigdzie hostowany, a instalowany na komputerze dowolnego klienta. W tej sytuacji rozumiem ręczne dodawanie IP w firewall AppService nie wchodzi w grę - nie wiadomo kto i kiedy zainstaluję appke dekstopową. Jak w takim razie udostępnić moje AppService tak naprawdę każdemu? Czy może inaczej powinno się to zrobić?

A nie lepiej sobie przejść na autentykacje JWT i tak się autoryzować do API z poziomu desktop appki?

Login, hasło -> strzał po token -> token na Singletona -> każdy kolejny request z headerem autoryzacyjnym

Ewentualnie, jeśli nie pozwalasz userom na rejestracje to jakiś API Key i też w headerze.

No to musisz otworzyć firewall na wszystkie ip. A masz autoryzacje do API?

Jak natomiast wygląda sytuacja w przypadku klientów desktopowych?

Tak samo jak w przypadku webowych, bo albo apka jest dostępna dla każdego bez ograniczeń, albo wprowadzasz jakieś mechanizmy uwierzytelniania (czy to będzie klucz dostępowy, konto, czy cokolwiek innego to już inna sprawa).

AppService domyślnie jest usługa publiczna i każdy kto zna URL hosta może z nią gadać. Aby zapewnić dostęp tylko wybranym klientom desktopowym, webowym, konsolowym i ch.. wie jakim, stosuje się mechanizmy uwierzytelnienia takie jak login/haslo, tokeny, klucze, certyfikaty.

Filtrowanie globalnego ruchu po IP to głupota. Takie rzeczy można robić przy rozwiązaniach hybrydowych gdzie część usług jest w sieci lokalnej a część w publicznej, chociaż i tak lepszym rozwiązaniem jest VPN albo Azure Express Route.

Dzięki za odpowiedzi. Tak logowanie normalnie w appce jest, także bez konta nikt poza endpointem do autentykacji więcej nie wywoła, jednak wszędzie czytałem, że po prostu nie powinno się na produkcji robić CORSa z ustawieniami AllowAll, a w tym przypadku i z tego co czytam nie ma innego wyjścia i trzeba tak postąpić.

Jeszcze jedna rzecz mi przyszła do głowy - może pomysł głupi, ale i tak napiszę ;)

Nie wiem w jakim celu masz to filtrowanie po IP, podejrzewam że względy bezpieczeństwa. Faktem jest, że można zrobić jakieś autoryzacje/tokeny i na tym bazować wystawiając usługę na cały świat, ale jednak bezpieczniej jest dla całego świata (poza dopuszczonymi adresami) pokazać, że niczego tutaj nie ma.

W każdym razie - można jeszcze zrobić taki scenariusz, że postawisz sobie jakiś serwerek (cokolwiek innego, niż ten AWS czy co tam masz) i apka desktopowa będzie się do niego wbijać najpierw. Zgłasza tam, że chce korzystać z API. Następnie ten serwerek przekaże do chmury informację, żeby na jakiś czas dodać adres desktopa do listy uprawnionych adresów. Po jakimś czasie nieaktywności adresy z listy będą czyszczone.

Tylko pytanie podstawowe - w jakim celu masz zrobione filtrowanie adresów IP żródłowych. Chodzi o bezpieczeństwo czy są inne powody?

CSharpBeginner napisał(a):

ednak wszędzie czytałem, że po prostu nie powinno się na produkcji robić CORSa z ustawieniami AllowAll, a w tym przypadku i z tego co czytam nie ma innego wyjścia i trzeba tak postąpić.

Od początku. CORS ma sens tylko w przypadku aplikacji webowych. Dlaczego? Ponieważ ma uniemożliwić wykonanie żądań w przeglądarce z aplikacji A do aplikacji B bez pozwolenia. W przypadku aplikacji mobilnych czy desktopowych taka sytuacja nie zachodzi (bo nie działają w przeglądarce), więc CORS nie ma sensu. Oczywiście poza specyficznymi przypadki jak korzystanie z WebView czy podobnych wynalazków.

strzelać sobie do niej lokalnie z postmana.

To raczej dość niedobre określenie, lokalne w tym kontekście myli. Po prostu jakie IP dopuściłeś takie masz dopuszczone.

nie wiadomo kto i kiedy zainstaluję appke dekstopową

No to tak wygląda życie jeśli udostępniasz coś dla mas w internecie. Po prostu musisz odblokować ruch dla całego świata, co pociągnie za sobą całą masę problemów. Ew. możesz ten cały świat zawęzić do trochę mniejszego świata, np. tylko do Polski jeśli np. twoja usługa ma sens w Polsce i boisz się niemieckich, ruskich, żydowskich, skośnych, afrykańskich hakerów. Do tego służą narzędzia typu WAF żeby blokować np. ruch z regionu X.