Logowanie SSO — częste pytania

Firma Adobe oferuje następujące typy identyfikatorów:

• Enterprise ID: Konto jest tworzone przez organizację i stanowi jej własność. Konta tworzy się w przypisanej wcześniej domenie. Adobe zarządza danymi identyfikacyjnymi i przetwarza logowanie.
• Federated ID: Organizacja tworzy konto i jest jego właścicielem, a także definiuje połączenie między tym kontem a swoim katalogiem korporacyjnym za pomocą usług federacji. Organizacja zarządza danymi uwierzytelniania i obsługuje logowanie, wykorzystując procesy SSO (pojedynczego logowania).
• Adobe ID: Użytkownik tworzy konto i jest jego właścicielem, natomiast Adobe zarządza danymi uwierzytelniania i przetwarza logowanie. Właścicielem konta i zasobów jest — w zależności od modelu przestrzeni dyskowej — użytkownik albo organizacja.
  

Tak. Można stosować kombinację identyfikatorów Adobe ID, Enterprise ID oraz Federated ID, nie można jednak łączyć różnych typów w ramach jednej domeny.

Identyfikatory Enterprise ID i Federated ID są unikatowe na poziomie domeny. Oznacza to, że można korzystać tylko z jednego z tych typów identyfikatorów. Natomiast identyfikatory Adobe ID można stosować w połączeniu z identyfikatorami Federated ID albo identyfikatorami Enterprise ID.

Na przykład jeśli przedsiębiorstwo przypisze tylko jedną domenę, administrator działu informatycznego może wybrać, że będzie ona obsługiwać albo identyfikatory Enterprise ID, albo Federated ID. Natomiast jeśli przedsiębiorstwo przypisze wiele domen, to administrator może przeznaczyć jedną z tych domen na identyfikatory Adobe ID oraz Enterprise ID, a kolejną na identyfikatory Adobe ID oraz Federated ID. Oznacza to, że w każdej z domen można stosować albo identyfikatory Enterprise ID, albo Federated ID, w obu przypadkach łącząc je z identyfikatorami Adobe ID.

W przypadku identyfikatorów Federated ID zarządzanie licencjami Adobe jest szybsze, łatwiejsze i bezpieczniejsze.

• Administratorzy działu informatycznego przedsiębiorstwa mają kontrolę nad uwierzytelnianiem oraz cyklem życia konta użytkownika.
• Usunięcie użytkownika z katalogu kont przedsiębiorstwa spowoduje, że nie będzie on już mieć dostępu do aplikacji stacjonarnych i mobilnych ani usług.
• Identyfikatory Federated ID umożliwiają przedsiębiorstwu korzystanie z już posiadanych systemów zarządzania identyfikatorami.
• Ponieważ użytkownicy końcowi korzystają ze standardowego systemu obsługi identyfikatorów w przedsiębiorstwie, dział informatyczny nie musi wdrażać odrębnego procesu zarządzania hasłami.

Podczas logowania użytkownicy końcowi są kierowani do standardowego i znajomego ekranu pojedynczego logowania, którego używa ich przedsiębiorstwo.

Tak. Można przełączyć się z identyfikatorów Enterprise ID na Federated ID, korzystając z tej samej domeny. Szczegółowe instrukcje podano w procedurze przenoszenia domen między katalogami.

Tak. Katalog kont przedsiębiorstwa oraz jego infrastrukturą logowania i uwierzytelniania można sfederować z systemami Adobe, korzystając z usługi IdP zgodnej z protokołem SAML 2.0.

Nie. Przypisanie domeny na potrzeby identyfikatorów Federated ID nie powoduje żadnych zmian w istniejących identyfikatorach Adobe ID opartych na adresach e-mail w tej domenie. Istniejące identyfikatory Adobe ID w serwisie Adobe Admin Console pozostaną niezmienione.

Migracja zasobów to proces automatyczny. Gdy go zainicjujesz, cała obsługiwana zawartość przechowywana obecnie na Twoim koncie Adobe ID zostanie przeniesiona na konto Enterprise ID/Federated ID. Więcej informacji: Automatyczna migracja zasobów.

Zaimplementowana przez Adobe obsługa identyfikatorów Federated ID obejmuje autoryzację, natomiast procedura uwierzytelniania jest przeprowadzana przez usługę IdP, z której korzysta przedsiębiorstwo.

Przedsiębiorstwa mogą nawiązać połączenie między swoimi usługami uwierzytelniania (z użyciem korporacyjnej struktury obsługi identyfikatorów, takiej jak Active Directory) a usługami Adobe. Umożliwia to przedsiębiorstwu obsługę uwierzytelniania. Adobe nigdy nie przechowuje haseł, a administratorzy działu informatycznego nie mogą resetować haseł ani edytować nazw użytkownika powiązanych z kontami Federated ID za pomocą serwisu Adobe Admin Console.

Tak. Można skorzystać z funkcji Importuj użytkowników dostępnej w serwisie Adobe Admin Console. Więcej informacji: Dodawanie wielu użytkowników.

Nie. Adobe nawiązuje połączenie z usługą dostawcy tożsamości (IdP) obsługującą przedsiębiorstwo, a nie bezpośrednio z katalogiem korporacyjnym tego przedsiębiorstwa. Jest jednak dostępna funkcja importowania informacji o użytkownikach i grupach z katalogu kont przedsiębiorstwa do serwisu Adobe Admin Console. Więcej informacji: Dodawanie wielu użytkowników.

Adobe zaleca wszystkim administratorom systemów przedsiębiorstw migrację użytkowników z kont Adobe ID na Federated ID. Procedurę takiej migracji podano tutaj.

Adobe stosuje bezpieczny i powszechnie przyjęty standard SAML (Security Assertion Markup Language), co umożliwia bezproblemową integrację implementacji logowania SSO z dowolną usługą IdP zgodną ze specyfikacją SAML 2.0.

Poniżej podano listę niektórych usług IdP zgodnych ze standardem SAML 2.0:

• Okta
• Oracle Identity Federation
• Microsoft ADFS
• Microsoft Azure AD^#
• Google Federation^# 
• Ping Federate
• Salesforce IdP z zewnętrznie podpisanym certyfikatem
• CA Federation
• ForgeRock OpenAM
• Shibboleth
• NetIQ Access Manager
• OneLogin
• Novell Access Manager

Tak, pod warunkiem, że jest to proces zgodny ze specyfikacją protokołu SAML 2.0.

Tak. Ponadto taka usługa IdP musi być zgodna ze standardem SAML 2.0.

Usługa IdP zgodna z protokołem SAML musi mieć co najmniej:

1. certyfikat IDP;
2. adres URL logowania IDP,
3. powiązanie IDP: HTTP-POST lub HTTP-Redirect;
4. adres URL usługi ACS (Assertion Consumer Service) wystawianej przez IdP; musi przyjmować żądania SAML oraz parametr RelayState.

W razie pytań należy skontaktować się z dostawcą usługi IdP.

Nie. Nigdy dotychczas nie złamano certyfikatu 2048-bitowego. Jedyna grupa, która złamała z powodzeniem certyfikat 768-bitowy (grupa Lenstra) ocenia, że złamanie certyfikatu zaledwie 1024-bitowego z użyciem tego samego sprzętu potrwałoby ponad 1000 lat — a jest to 32 000 000 razy łatwiejsze niż złamanie certyfikatu 2048-bitowego.

Jeśli interesują Cię takie ciekawostki dotyczące szacunkowych danych o możliwości złamania certyfikatów różnej długości, zajrzyj na tę stronę WWW. Zabawne (dokładne, ale nacechowane marketingowo) ujęcie bezpieczeństwa tych certyfikatów można znaleźć w tym serwisie WWW (oraz w jego źródłowym serwisie matematycznym).

Nie będzie to problemem. Ten limit dotyczy tylko certyfikatów służących do szyfrowania kanału komunikacyjnego między przeglądarką a serwerem. Natomiast certyfikaty IdP są używane do podpisywania (a nie szyfrowania) danych wymienianych przez już zaszyfrowany kanał. Przeglądarka w ogóle nie analizuje tych certyfikatów. Są one używane tylko w komunikacji pomiędzy Adobe/ a usługą IdP, z której korzysta klient.

Dobry certyfikat 2048-bitowy klasy komercyjnej kosztuje około 10 $ za rok obowiązywania. Ponadto certyfikaty używane przez usługi IdP mogą być samopodpisane, co oznacza, że można je generować bezpłatnie z użyciem oprogramowania open source.

Nie. Wynika to z faktu, że stosowane są jeszcze dwie warstwy silnego szyfrowania, które sprawdzają tożsamość usługi IdP. Aby się pod nią podszyć, konieczne byłoby złamanie także obu tych warstw. Co więcej, żadna z tych dwóch warstw nie używa certyfikatów samopodpisanych. Oznacza to, że trzeba by złamać nie tylko certyfikat wprowadzający szyfrowanie, ale także certyfikat źródła podpisu, które wygenerowało tamten certyfikat szyfrujący.

Numer telefonu i adres e-mail umożliwiający kontakt z pomocą techniczną na poziomie premium podano w powitalnej wiadomości e-mail z załącznikiem PDF, która została wysłana do administratora konta.

Wiele katalogów może korzystać z tego samego punktu końcowego URL. Jednak metadane federacji będą zarządzane odrębnie dla każdej z usług IdP. Zatem wspólny punkt końcowy IdP będzie musiał obsługiwać żądania o różnej zawartości.

Tak, jeśli integracja SAML katalogu używa formatu username, a nazwy kont użytkowników w systemie Admin Console są tożsame z przekazanymi trwałymi identyfikatorami. Jednak wymagałoby to dostępności trwałych identyfikatorów w momencie, gdy konta użytkowników są synchronizowane z systemem Admin Console. Nie jest to często spotykany scenariusz, dlatego też w praktyce trwały format elementu NameID nie byłby obsługiwany.

Nie. Wartość elementu NameID jest używana jako nazwa konta w systemie Admin Console; wartość atrybutu NameQualifier jest pomijana.

Tak. Adobe obsługuje certyfikaty SHA256. Więcej informacji: Konfigurowanie identyfikatorów.

Tak. Administrator musi przekazać działowi obsługi klienta Adobe certyfikaty podpisane przez źródło certyfikacji (CA). Adobe prześle je do użycia przez dostawcę usługi.

Aby to zrobić, zaloguj się w serwisie Admin Console, przejdź do sekcji Pomoc techniczna > Podsumowanie pomocy technicznej i kliknij opcję Utwórz zgłoszenie. Więcej informacji: Tworzenie zgłoszeń pomocy technicznej i zarządzanie nimi.

Domyślnie certyfikaty Okta są samopodpisane. Wyjątkowo (i ewentualnie za opłatą) certyfikaty może podpisywać publiczne źródło certyfikacji.