brak wsparcia dla SSO między CRM a e-mail

Brak wsparcia dla SSO między CRM a e-mail to ograniczenie zmuszające do oddzielnego logowania się do obu tych systemów.

Na czym polega brak SSO między CRM a pocztą

Brak wsparcia dla SSO między systemem CRM a pocztą elektroniczną oznacza, że oba systemy nie korzystają ze wspólnego mechanizmu uwierzytelniania. Użytkownik może mieć konto w CRM oraz konto pocztowe przypisane do tego samego adresu e-mail, ale samo podobieństwo danych logowania nie tworzy jeszcze jednokrotnego logowania. Każda aplikacja osobno sprawdza tożsamość użytkownika, utrzymuje własną sesję i może wymagać odrębnego hasła, kodu wieloskładnikowego albo ponownego potwierdzenia dostępu.

SSO, czyli Single Sign-On, działa inaczej. Użytkownik uwierzytelnia się u zaufanego dostawcy tożsamości, a następnie aplikacja docelowa otrzymuje potwierdzenie, że uwierzytelnienie zakończyło się powodzeniem. W zależności od zastosowanej architektury wymiana informacji może wykorzystywać między innymi SAML 2.0 albo OpenID Connect działający na OAuth 2.0. Jeżeli CRM i system pocztowy nie obsługują tego samego dostawcy tożsamości lub nie mają skonfigurowanej odpowiedniej integracji, logowanie do jednego systemu nie ustanawia sesji w drugim.

Skutki rozdzielenia kont, sesji i haseł

Najbardziej widocznym skutkiem jest konieczność wykonania dwóch operacji logowania. Zamknięcie sesji w CRM nie musi wylogować użytkownika z poczty, a wylogowanie z poczty nie musi unieważnić sesji CRM. Dzieje się tak dlatego, że aplikacje przechowują niezależne znaczniki sesji, zwykle w postaci ciasteczek przeglądarkowych lub tokenów. Wspólna przeglądarka nie oznacza wspólnej sesji, nawet gdy oba systemy są otwierane w tej samej karcie albo pod podobną domeną.

Rozdzielenie uwierzytelniania komplikuje także zarządzanie cyklem życia kont. Zmiana hasła w jednym systemie nie musi zmienić hasła w drugim. Podobnie zablokowanie konta, usunięcie użytkownika, wymuszenie dodatkowego uwierzytelnienia lub zakończenie aktywnych sesji może dotyczyć tylko jednego systemu. Administrator musi wtedy kontrolować zgodność identyfikatorów użytkowników, adresów e-mail, statusów kont oraz przypisanych uprawnień w dwóch niezależnych miejscach.

Brak SSO nie oznacza automatycznie, że CRM albo poczta działają nieprawidłowo. Jest to ograniczenie integracji tożsamości, a niekoniecznie awaria samej aplikacji. Może jednak zwiększać liczbę czynności wykonywanych przez użytkownika i utrudniać ustalenie, który system odrzucił dane logowania. Ten sam komunikat, na przykład o nieprawidłowym haśle, może pochodzić z CRM, dostawcy poczty, strony pośredniej albo z mechanizmu uwierzytelniania wieloskładnikowego.

Rozróżnienie SSO od przekazywania poczty i synchronizacji danych

Jednokrotne logowanie nie jest tym samym co integracja skrzynki pocztowej z CRM. CRM może pobierać wiadomości, rejestrować korespondencję przy kontaktach, wysyłać e-maile albo wyświetlać kalendarz, a mimo to wymagać oddzielnego logowania. Takie funkcje dotyczą wymiany danych i uprawnień aplikacyjnych. SSO dotyczy przede wszystkim sposobu potwierdzania tożsamości oraz tworzenia i kończenia sesji użytkownika.

Nie należy też utożsamiać SSO z przechowywaniem jednego hasła w obu systemach. Identyczne hasła nie zapewniają wspólnej sesji ani bezpiecznej federacji tożsamości. W poprawnej integracji aplikacja nie powinna otrzymywać hasła użytkownika od innego systemu tylko dlatego, że użytkownik chce korzystać z obu usług. Zamiast tego może otrzymać podpisane twierdzenie SAML albo token tożsamości OpenID Connect, którego odbiorca i zakres zastosowania są określone w konfiguracji.

W praktyce trzeba osobno analizować cztery elementy: dostawcę tożsamości, aplikację CRM, system pocztowy oraz przeglądarkę lub klienta pocztowego. Nawet gdy oba systemy deklarują obsługę SSO, integracja może wymagać zgodności adresów przekierowania, identyfikatora użytkownika, certyfikatu podpisującego, zakresów tokenu, czasu ważności sesji i sposobu wylogowania. Brak jednego z tych elementów może prowadzić do ponownego pytania o hasło albo do pętli przekierowań.

Jak rozpoznać i opisać ograniczenie w środowisku użytkownika

Podczas analizy warto najpierw ustalić, czy oba logowania odbywają się na stronach należących do różnych systemów, czy jedno z nich przekierowuje do wspólnego dostawcy tożsamości. Należy zanotować dokładny adres strony logowania, treść komunikatu, moment wystąpienia problemu oraz to, czy druga aplikacja pozostaje zalogowana po wylogowaniu z pierwszej. Pomocne jest także sprawdzenie zachowania w prywatnym oknie przeglądarki i w innej przeglądarce, ponieważ zapisane ciasteczka mogą ukrywać faktyczny przebieg uwierzytelniania.

Jeżeli użytkownik wpisuje osobne dane w CRM i poczcie, a oba systemy działają poprawnie po niezależnym zalogowaniu, obserwacja wskazuje raczej na brak federacji tożsamości niż na usterkę sprzętową. Jeżeli natomiast pojawia się pętla przekierowań, niezgodność konta, odrzucenie tokenu lub komunikat o braku uprawnień, potrzebne są logi dostawcy tożsamości i aplikacji. Trzeba wtedy odróżnić błąd uwierzytelniania, czyli niepotwierdzenie tożsamości, od błędu autoryzacji, czyli odmowy dostępu do konkretnej funkcji.

Na komputerze można również sprawdzić, czy problem występuje wyłącznie w jednej przeglądarce, na jednym profilu użytkownika albo po zmianie hasła. Nie należy jednak usuwać konfiguracji kont ani resetować haseł bez ustalenia, który system jest źródłem problemu. W przypadku braku obsługi SSO właściwym opisem będzie informacja o dwóch niezależnych mechanizmach logowania, a nie stwierdzenie awarii poczty, CRM lub komputera. Neutralne rozpoznanie ograniczenia pomaga dobrać dalsze działania do faktycznej architektury systemów.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę lokalnych przyczyn problemów z logowaniem do aplikacji biznesowych.