Poprzez zewnętrzną usługę hostingu udostępniłem aplikację internetową przeznaczoną dla pracowników naszej firmy. Aplikacja wymaga oczywiście zalogowania, a aktualnie założone jest wyłącznie konto serwisowe z uprawnieniami administratora aplikacji. Chciałbym, aby pracownicy logowali się z użyciem poświadczeń Active Directory, czyli tak, jak obecnie logują się na firmowych urządzeniach. Z wiadomych powodów nie możemy wystawić usługi LDAP na zewnątrz, a hosting odmówił zestawienia połączenia VPN do naszej sieci. Posiadamy jednak możliwość wystawienia innej usługi, która pozwoli na logowanie kontami Active Directory. Czy możesz podać przykład takiego rozwiązania? Pracownicy niekoniecznie będą korzystać z tej aplikacji, znajdując się w firmie. Dodatkowo chciałbym uniknąć kosztów, więc zależy mi na bezpłatnych narzędziach (nie dotyczy to ewentualnych licencji na systemy operacyjne). Preferuję rozwiązania self-hosted, które nie są zależne od żadnych zewnętrznych usług. Większe doświadczenie mam też z rozwiązaniami Microsoft.
Apr 13, 9:51am

W Twojej sytuacji, gdzie chcesz umożliwić logowanie pracowników do zewnętrznej aplikacji internetowej za pomocą poświadczeń Active Directory, ale nie możesz wystawić LDAP na zewnątrz ani zestawić VPN, dobrym rozwiązaniem będzie zastosowanie protokołu OAuth 2.0/OIDC (OpenID Connect) z wykorzystaniem usługi, która będzie pełniła rolę brokera uwierzytelniania.

Proponowane rozwiązanie: Azure Active Directory Application Proxy + Self-Hosted Identity Provider

Jeśli korzystacie z Microsoft Azure AD (nawet w wersji darmowej), możecie wykorzystać Azure AD Application Proxy, który umożliwia bezpieczne udostępnianie wewnętrznych aplikacji (w tym usług uwierzytelniania) na zewnątrz bez otwierania portów LDAP/VPN. Jednak skoro preferujesz rozwiązania self-hosted i bez dodatkowych kosztów, warto rozważyć self-hosted Identity Provider (IdP).

1. Self-Hosted Identity Provider (IdP) z integracją z Active Directory

Możesz postawić własny serwer uwierzytelniania, który będzie pełnił rolę brokera między aplikacją a Active Directory. Przykładowe rozwiązania:

A. Keycloak

  • Dlaczego Keycloak?
    Keycloak to otwartoźródłowy serwer uwierzytelniania i autoryzacji, który obsługuje protokoły OAuth 2.0, OpenID Connect i SAML 2.0. Można go zintegrować z Active Directory za pomocą LDAP Federation lub Kerberos (SPNEGO).
  • Jak to działa?
    1. Keycloak jest wystawiony na zewnątrz (np. jako podstrona Twojej aplikacji).
    2. Użytkownik loguje się przez Keycloak, który komunikuje się z wewnętrznym Active Directory (np. przez LDAP w sieci firmowej).
    3. Po pomyślnym uwierzytelnieniu, Keycloak zwraca token JWT do aplikacji.
  • Zalety:
    • Darmowy i otwartoźródłowy.
    • Możliwość integracji z LDAP (Active Directory).
    • Obsługa MFA (jeśli będzie potrzebna).
    • Możliwość hostowania na własnym serwerze.
  • Wady:
    • Wymaga konfiguracji i utrzymania.
    • Konieczność zabezpieczenia samego Keycloaka (np. certyfikaty SSL, firewall).

Przykładowa architektura:

text
[Przeglądarka użytkownika] → [Zewnętrzna aplikacja] → [Keycloak (self-hosted)] → [Active Directory (LDAP)]

B. Dex (CoreOS)

  • Dlaczego Dex?
    Dex to prosty, otwartoźródłowy broker uwierzytelniania, który może działać jako "pośrednik" między aplikacją a Active Directory.
  • Jak to działa?
    1. Dex jest wystawiony na zewnątrz.
    2. Użytkownik loguje się przez Dex, który komunikuje się z Active Directory (np. przez LDAP).
    3. Dex zwraca token JWT do aplikacji.
  • Zalety:
    • Lekki i prosty w konfiguracji.
    • Obsługa LDAP (Active Directory).
    • Możliwość integracji z OAuth 2.0/OIDC.
  • Wady:
    • Mniej funkcji niż Keycloak (np. brak wbudowanego MFA).

2. Integracja z Microsoft Azure AD (jeśli macie subskrypcję)

Jeśli korzystacie z Microsoft 365 lub Azure AD, możecie użyć Azure AD Application Proxy lub Azure AD B2C (w wersji darmowej) do uwierzytelniania. Jednak skoro preferujesz rozwiązania self-hosted, Keycloak lub Dex będą lepszym wyborem.

3. Alternatywa: AD FS (Active Directory Federation Services)

Jeśli macie Windows Server, możecie użyć AD FS (Active Directory Federation Services) jako brokera uwierzytelniania. AD FS obsługuje protokoły SAML 2.0 i OAuth 2.0, ale wymaga wystawienia na zewnątrz (co może być problematyczne bez VPN).

Podsumowanie: Rekomendowane rozwiązanie

Keycloak
IdP
Tak (LDAP)
Tak
Tak
Najbardziej elastyczne
Dex
Broker
Tak (LDAP)
Tak
Tak
Prostsze, mniej funkcji
AD FS
IdP
Tak (natywnie)
Tak
Tak
Wymaga Windows Server
Azure AD Proxy
Broker
Tak (natywnie)
Nie
Częściowo
Wymaga Azure AD

Rekomendacja:

Keycloak jest najlepszym wyborem, jeśli szukasz darmowego, self-hosted rozwiązania z pełną kontrolą i możliwością integracji z Active Directory. Możesz go postawić na własnym serwerze (np. Linux/Windows) i skonfigurować jako broker uwierzytelniania dla Twojej aplikacji.

Kroki wdrożeniowe dla Keycloak:

  1. Zainstaluj Keycloak na serwerze (np. Linux/Windows).
  2. Skonfiguruj połączenie z Active Directory (LDAP Federation).
  3. Utwórz klienta OAuth 2.0 dla Twojej aplikacji.
  4. Zintegruj aplikację z Keycloak (np. przez biblioteki OAuth 2.0/OIDC).
  5. Wystaw Keycloak na zewnątrz (zabezpieczony SSL).

Czy chciałbyś, abym przygotował szczegółowy przewodnik konfiguracyjny dla jednego z tych rozwiązań?

Apr 13, 9:51am

This is a shared conversation and may include unverified content that doesn't reflect Mistral AI's views. Login to resume chatting.