Active Directory jest nadal autorytatywnym katalogiem użytkowników w wielu organizacjach. Użytkownicy, hasła i członkostwa w grupach często już tam mieszkają, a w wielu przypadkach dzieje się tak od lat.
Jednak nowoczesne aplikacje często wymagają nowoczesnych protokołów federacyjnych i silniejszych opcji uwierzytelniania.
Nowe aplikacje internetowe, platformy SaaS i portale skierowane do klientów często obsługują OpenID Connect lub SAML 2.0. Oczekują nowoczesnych tokenów, claims, metadanych federacyjnych, przepływów pojedynczego logowania, a czasami zwiększonego uwierzytelniania za pomocą MFA.
Stwarza to wspólne wyzwanie: jak zmodernizować uwierzytelnianie bez konieczności wymiany Active Directory od pierwszego dnia?
W tym miejscu przydatny staje się FoxIDs Directory Connector for Active Directory. Pozwala organizacjom zachować Active Directory jako źródło użytkowników, haseł i członkostw w grupach, podczas gdy FoxIDs dodaje na wierzch nowoczesną warstwę tożsamości.
Użytkownicy nadal mogą logować się przy użyciu istniejących danych uwierzytelniających Active Directory. Aplikacje można zintegrować z FoxIDs za pomocą OpenID Connect lub SAML 2.0. FoxIDs może dodawać claims, role, uwierzytelnianie wieloskładnikowe i możliwość logowania markowego w ramach istniejącego katalogu.
Active Directory może pozostać tam, gdzie jest
Wiele organizacji nie oczekuje gwałtownej migracji z Active Directory. Muszą po prostu sprawić, aby ich istniejący katalog działał z nowoczesnymi aplikacjami.
Dzięki Directory Connector for Active Directory, FoxIDs łączy się z komponentem zainstalowanym w środowisku Windows klienta, w pobliżu kontrolerów domeny. FoxIDs wywołuje łącznik poprzez HTTPS, a łącznik sprawdza poprawność użytkowników, obsługuje operacje na hasłach i zwraca wybrane właściwości użytkownika i claims z Active Directory.
Ważną częścią jest to, że Active Directory pozostaje wiarygodny.
Oznacza to, że hasła nadal mogą być sprawdzane przez usługę AD. Istniejące zasady dotyczące haseł mogą nadal obowiązywać. Użytkownikami można nadal zarządzać w znanym katalogu. Członkostwo w grupie może być nadal kontrolowane przez istniejące procesy IT.
FoxIDs staje się wówczas nowoczesną warstwą tożsamości przed usługą AD.
Zamiast łączyć każdą aplikację bezpośrednio z Active Directory lub LDAP, aplikacje łączą się z FoxIDs. FoxIDs obsługuje protokół federacyjny, wydawanie tokenów, claims i przepływ uwierzytelniania, podczas gdy katalog bazowy pozostaje usługą AD.
Daje to organizacjom praktyczną ścieżkę migracji. Mogą zacząć od zatrzymania użytkowników w Active Directory, a później przenieść ich do FoxIDs, jeśli ma to sens. Przejście nie musi nastąpić od razu.
OIDC i SAML 2.0 dla istniejących użytkowników AD
Główna wartość jest prosta: obecni użytkownicy Active Directory mogą logować się do nowoczesnych aplikacji OpenID Connect i SAML 2.0 poprzez FoxIDs.
W przypadku aplikacji OpenID Connect FoxIDs pełni rolę dostawcy OpenID. Aplikacje mogą korzystać z wykrywania, uwierzytelniania, wylogowywania i punktu końcowego UserInfo. FoxIDs obsługuje również PKCE i różne opcje uwierzytelniania klienta.
W przypadku aplikacji SAML 2.0 FoxIDs może wystawiać potwierdzenia SAML i działać jako dostawca tożsamości dla aplikacji, które opierają się na korporacyjnym logowaniu jednokrotnym opartym na SAML.
Jest to przydatne, gdy organizacja ma różne typy aplikacji. Jedna aplikacja może wykorzystywać OpenID Connect. Inny może nadal wymagać SAML 2.0. Trzeci może później potrzebować tokenów dostępu OAuth 2.0 do interfejsów API.
Użytkownicy mogą nadal być tymi samymi użytkownikami usługi AD.
Pozwala to uniknąć sytuacji, w której organizacja musi duplikować użytkowników, tworzyć niestandardowe integracje LDAP lub migrować tożsamości, zanim pierwsza nowoczesna aplikacja będzie mogła zostać uruchomiona.
Zamiast tego FoxIDs może wypełnić lukę pomiędzy istniejącym katalogiem a protokołami, których oczekują nowoczesne aplikacje.
Używaj grup AD jako nowoczesnych claims aplikacji
Uwierzytelnianie to tylko część historii. Aplikacje muszą także wiedzieć, kim jest użytkownik i do czego może uzyskać dostęp.
Active Directory często zawiera już te informacje poprzez członkostwo w grupach. Użytkownik może być członkiem grupy Pracownicy, grupy Administratorzy, grupy Finanse lub grupy Obsługi Klienta.
Directory Connector może zwracać skonfigurowane atrybuty AD jako claims i skonfigurować członkostwa w grupach AD jako claims. claims grupowe są zwykle zwracane jako claims ról i można uwzględnić grupy zagnieżdżone.
Dzięki temu możliwe jest wykorzystanie istniejących struktur grup AD w nowoczesnych aplikacjach.
Na przykład grupę AD, taką jak Pracownicy, można zwrócić jako claim roli z wartością Pracownicy. Aplikacja nie musi rozumieć LDAP ani bezpośrednio wysyłać zapytań do Active Directory. Wystarczy przeczytać claims wydane przez FoxIDs.
Poniższy zrzut ekranu przedstawia użytkownika Active Directory, który jest członkiem grupy Pracownicy. To jest istniejące członkostwo w grupie, które jest już zarządzane w Active Directory.
Gdy użytkownik zaloguje się za pośrednictwem FoxIDs, członkostwo w grupie AD może zostać uwzględnione jako claim roli w wydanym tokenie aplikacji. W tym przykładzie grupa Pracownicy jest zwracana jako żądanie roli.
Aplikacja nie musi bezpośrednio wysyłać zapytań do Active Directory. Wystarczy przeczytać claims wydane przez FoxIDs.
To jest czysty podział obowiązków.
Active Directory pozostaje miejscem zarządzania członkostwem. FoxIDs przekształca te informacje katalogowe w nowoczesne claims dotyczące tożsamości. Aplikacja odbiera wynik w protokole, który już obsługuje.
Dodaj MFA na górze loginu Active Directory
Główną zaletą używania FoxIDs przed Active Directory jest to, że można usprawnić logowanie bez konieczności wymiany katalogu.
FoxIDs obsługuje zarówno proste uwierzytelnianie dwuskładnikowe, jak i zaawansowane uwierzytelnianie wieloskładnikowe w metodzie uwierzytelniania logowania. Obsługiwane wbudowane czynniki obejmują kod SMS, kod e-mail, kod aplikacji uwierzytelniającej i kod odzyskiwania. FoxIDs może również wykorzystywać inne metody uwierzytelniania, takie jak OIDC lub SAML 2.0, jako kroki MFA.
MFA może być wymagany na kilka sposobów.
Można ją włączyć dla wybranych użytkowników. Może być wymagany w metodzie uwierzytelniania logowania. Lub aplikacja może w razie potrzeby zażądać MFA. W przypadku OpenID Connect, aplikacja może zażądać MFA z acr_values=urn:foxids:mfa. W przypadku SAML 2.0 można zażądać MFA poprzez kontekst uwierzytelniania.
Jest to cenne, ponieważ nie wszystkie aplikacje wymagają przez cały czas tego samego poziomu pewności.
Normalna aplikacja wewnętrzna może potrzebować jedynie nazwy użytkownika i hasła. Wrażliwy portal administracyjny może za każdym razem wymagać MFA. Inna aplikacja może żądać MFA tylko w przypadku określonych działań lub sesji o wyższym ryzyku.
FoxIDs może obsługiwać tego rodzaju model stopniowy, podczas gdy pierwszy czynnik jest nadal sprawdzany w porównaniu z Active Directory.
W praktyce oznacza to, że organizacje mogą zachować usługę AD jako źródło użytkownika i hasła, jednocześnie dodając nowoczesne mechanizmy bezpieczeństwa podczas logowania.
Lepsza ścieżka migracji
Zastąpienie katalogu tożsamości rzadko jest decyzją techniczną. Wpływa na użytkowników, aplikacje, operacje IT, zasady bezpieczeństwa i procesy wsparcia.
Dlatego liczy się stopniowa ścieżka.
Dzięki FoxIDs organizacja może zacząć od podłączenia Active Directory i umożliwienia użytkownikom logowania się przy użyciu istniejących pclaims. FoxIDs może przechowywać wewnętrzny rekord użytkownika z identyfikatorami, właściwościami, claimsmi, ustawieniami MFA i przypisaniami dostępu, podczas gdy katalog zewnętrzny pozostaje autorytatywny dla sprawdzania poprawności haseł i zmian haseł.
Później, jeśli organizacja będzie chciała w pełni przenieść użytkowników do FoxIDs, będzie mogła to zrobić.
Jest to szczególnie przydatne dla organizacji, które chcą najpierw zmodernizować uwierzytelnianie, a później zdecydować o migracji użytkowników. Przydaje się to także wtedy, gdy różne grupy użytkowników poruszają się z różną prędkością. Pracownicy mogą pozostać w AD. Użytkownicy zewnętrzni mogą już mieszkać w FoxIDs. Nowe aplikacje mogą wykorzystywać OIDC. Starsze aplikacje korporacyjne mogą używać SAML 2.0.
FoxIDs może usiąść pośrodku i sprawić, że te światy będą ze sobą współdziałać.
Markowe doświadczenie logowania
Nowoczesne uwierzytelnianie to nie tylko protokoły i bezpieczeństwo. Doświadczenie użytkownika również ma znaczenie.
Gdy użytkownicy są przekierowywani do logowania, strona logowania powinna wyglądać znajomo i wiarygodnie. FoxIDs obsługuje dostosowanie sposobu logowania, w tym tytuł przeglądarki, ikonę przeglądarki i CSS. Ten sam proces logowania może również poprowadzić użytkowników przez uwierzytelnianie wieloskładnikowe, gdy wymagane jest większe bezpieczeństwo.
Jest to przydatne zarówno w scenariuszach wewnętrznych, jak i skierowanych do klienta.
Login pracownika może wykorzystywać nazwę i styl organizacji, jednocześnie dodając MFA do istniejącej nazwy użytkownika i hasła Active Directory. Portal klienta może wykorzystywać markę klienta. Aplikacja przeznaczona dla partnerów może mieć dostosowane środowisko logowania bez zmiany podstawowej integracji usługi AD.
Poniższy przykład przedstawia markowy ekran logowania MFA dla fikcyjnej firmy Northbridge Systems. Użytkownik loguje się na istniejące konto, a następnie jest proszony o dokończenie uwierzytelniania dwuskładnikowego SMS w FoxIDs.
Pełny kod CSS użyty w tym przykładzie znajduje się na końcu artykułu.
Rezultatem jest pełniejsza warstwa tożsamości: nowoczesne protokoły, użytkownicy wspierani przez AD, claims, MFA i markowy przepływ logowania.
Rozpoczęcie
Na początek nie jest wymagana migracja każdej aplikacji lub użytkownika.
Typowym pierwszym krokiem jest instalacja Directory Connector for Active Directory w środowisku Windows, w którym może uzyskać dostęp do kontrolerów domeny. Stamtąd FoxIDs może weryfikować użytkowników poprzez złącze i wydawać nowoczesne odpowiedzi OpenID Connect lub SAML 2.0 do aplikacji.
Konfiguracja staje się wówczas procesem przyrostowym. Zacznij od jednej aplikacji, zmapuj atrybuty AD i członkostwa w grupach, których potrzebuje aplikacja, zdecyduj, czy MFA powinien być wymagany i opcjonalnie customise logowania.
Gdy pierwsza aplikacja zadziała, ten sam wzór można ponownie wykorzystać w kolejnych aplikacjach. Niektórzy mogą używać OpenID Connect, inni mogą używać SAML 2.0, a wrażliwe aplikacje mogą w razie potrzeby wymagać MFA.
Szczegółowe kroki konfiguracji można znaleźć w dokumentacji FoxIDs Directory Connector for Active Directory.
Wniosek
Active Directory nadal ma kluczowe znaczenie dla wielu organizacji, ale nowoczesne aplikacje wymagają nowoczesnego uwierzytelniania.
FoxIDs Directory Connector for Active Directory umożliwia zachowanie istniejących użytkowników AD, haseł i grup, jednocześnie umożliwiając OpenID Connect, SAML 2.0, claims i MFA do FoxIDs.
Daje organizacjom praktyczny sposób na modernizację uwierzytelniania, poprawę bezpieczeństwa i obsługę nowych aplikacji bez konieczności wymiany wszystkiego na raz.
Dla wielu organizacji jest to najbardziej realistyczna droga naprzód: zachować to, co już działa, dodać na wierzch nowoczesną warstwę tożsamości i przeprowadzić migrację, gdy firma będzie gotowa.
Przykład CSS dla markowego ekranu logowania
Powyższy zrzut ekranu wykorzystuje poniższy CSS do stylizacji strony logowania FoxIDs dla fikcyjnej firmy Northbridge Systems. Zmienia nazwę firmy, paletę kolorów, tło strony, kartę logowania, kolor fokusa wejściowego, przyciski, linki i komunikat informacyjny.
W FoxIDs, ten CSS można dodać na zakładce Login UI metody uwierzytelniania logowania wraz z tytułem przeglądarki i ikoną przeglądarki.
:root {
--brand-primary: #16324f;
--brand-primary-dark: #0f2439;
--brand-accent: #1f8a8a;
--brand-accent-dark: #176d6d;
--brand-accent-soft: #e9f6f6;
--brand-bg: #f4f8fb;
--brand-surface: rgba(255, 255, 255, 0.97);
--brand-border: #dbe5ec;
--brand-text: #14202b;
--brand-muted: #5f6f7f;
}
/* Page background */
body {
background:
radial-gradient(circle at top right, rgba(31, 138, 138, 0.12), transparent 28rem),
radial-gradient(circle at bottom left, rgba(22, 50, 79, 0.10), transparent 26rem),
linear-gradient(135deg, #ffffff 0%, var(--brand-bg) 100%);
color: var(--brand-text);
}
/* Page spacing */
.container.body-content {
padding-top: 3.5rem;
padding-bottom: 3.5rem;
}
/* Main content card */
.page-content {
background: var(--brand-surface);
border: 1px solid var(--brand-border);
border-radius: 1.25rem;
box-shadow: 0 1.25rem 3rem rgba(15, 36, 57, 0.10);
padding: 2.25rem 2.5rem;
}
/* Brand block */
.brand-content {
margin-bottom: 2rem;
}
/* Hide default text and replace with fictive company name */
.brand-content-text {
visibility: hidden;
height: auto;
}
.brand-content-text::before {
content: "Northbridge Systems";
visibility: visible;
display: block;
color: var(--brand-primary);
font-size: 2.9rem;
font-weight: 600;
line-height: 1.05;
letter-spacing: -0.03em;
}
.brand-content-text::after {
content: "Secure Login";
visibility: visible;
display: block;
color: var(--brand-accent);
font-size: 1.15rem;
font-weight: 500;
margin-top: 0.35rem;
letter-spacing: 0.01em;
}
/* Hide the default icon if you want a clean text-led brand */
.brand-content-icon {
display: none;
}
/* Main headings, e.g. SMS two-factor */
h1, .h1 {
color: var(--brand-primary);
font-weight: 300;
letter-spacing: -0.03em;
margin-bottom: 1.5rem;
}
/* General supporting text */
.info-message,
.info-message-filter,
.help-block,
.text-muted,
small {
color: var(--brand-muted) !important;
}
/* Labels */
label,
.label-control {
color: var(--brand-primary) !important;
font-weight: 500;
}
/* Inputs */
.form-control,
.input-control {
border: 1px solid #cfd9e2;
border-radius: 0.5rem;
color: var(--brand-text);
min-height: 2.8rem;
background-color: #ffffff;
}
.form-control:focus,
.input-control:focus,
.input:focus {
border-color: var(--brand-accent);
box-shadow: 0 0 0 0.2rem rgba(31, 138, 138, 0.18);
outline: none !important;
}
/* Primary button */
.btn-primary,
.btn-primary:hover,
.btn-primary:focus,
.btn-primary:active,
.btn-primary:not(:disabled):not(.disabled).active,
.btn-primary:not(:disabled):not(.disabled):active,
.show > .btn-primary.dropdown-toggle {
color: #ffffff;
background-color: var(--brand-primary);
border-color: var(--brand-primary);
border-radius: 0.5rem;
font-weight: 500;
padding-left: 1.15rem;
padding-right: 1.15rem;
}
.btn-primary:hover,
.btn-primary:active,
.btn-primary:not(:disabled):not(.disabled):active {
background-color: var(--brand-primary-dark);
border-color: var(--brand-primary-dark);
}
.btn-primary:focus,
.btn-primary:not(:disabled):not(.disabled).active:focus,
.btn-primary:not(:disabled):not(.disabled):active:focus,
.show > .btn-primary.dropdown-toggle:focus {
box-shadow: 0 0 0 0.2rem rgba(22, 50, 79, 0.22);
}
/* Disabled button */
.btn-primary.disabled,
.btn-primary:disabled {
color: #ffffff;
background-color: #8ea3b7;
border-color: #8ea3b7;
}
/* Links */
a,
a:hover,
.btn-link,
.btn-link:hover,
.btn-link:focus,
.btn-link:not(:disabled):not(.disabled):active,
.btn-link:not(:disabled):not(.disabled).active,
.show > .btn-link.dropdown-toggle {
color: var(--brand-accent-dark);
text-decoration: none;
}
a:hover,
.btn-link:hover {
text-decoration: underline;
}
/* Checkbox */
.form-check-label {
color: var(--brand-text) !important;
font-weight: 400;
}
/* Optional info panel before or inside login box */
div.page-content::before {
content: "Sign in with your company account. Multi-factor authentication may be required for added security.";
display: block;
background: var(--brand-accent-soft);
color: var(--brand-primary);
border: 1px solid #cfe7e7;
border-radius: 0.75rem;
padding: 0.9rem 1rem;
margin-bottom: 1.5rem;
font-size: 0.96rem;
line-height: 1.45;
}
/* Footer */
.footer,
footer {
color: var(--brand-muted);
font-size: 0.85rem;
}
/* Mobile */
@media (max-width: 767.98px) {
.container.body-content {
padding-top: 1.5rem;
padding-bottom: 1.5rem;
}
.page-content {
border-radius: 0.9rem;
padding: 1.5rem;
box-shadow: 0 0.75rem 2rem rgba(15, 36, 57, 0.08);
}
.brand-content-text::before {
font-size: 2.2rem;
}
.brand-content-text::after {
font-size: 1rem;
}
}