Zrozumienie zarządzania sesjami Drupala i uwierzytelniania użytkowników

Mam wymaganie, w którym muszę zastąpić domyślne uwierzytelnianie użytkownika uwierzytelnieniem serwera centralnego, tj. Serwera SSO.
Debugując Drupala dowiedziałem się, że zarządzanie sesjami odbywa się w includes/session.incplikach. Chcę przeprowadzić uwierzytelnianie, jak pokazano na obrazku:

SCENARIUSZ: Zaloguj się
Szczegóły tych kroków to:

1. Zastąp formularz logowania, aby podać nazwę użytkownika i hasło na serwerze SSO ( nie na Drupal , ale na .NET).
2. Uwierzytelnij użytkownika na serwerze SSO przy użyciu bazy danych tej witryny; i odeślij odpowiedź na niestandardową stronę PHP mojej witryny (lub formularz przez moduł?).
3. Korzystając z odpowiedzi, zidentyfikuj użytkownika w tabeli użytkowników i utwórz sesję dla tego użytkownika bez sprawdzania hasła (ponieważ oznaczałoby to podwójne uwierzytelnienie). Domyślnie Drupal ustawia plik cookie o nazwie $insecure_session_namezmiennej i wartości$sid . Chcę, aby Drupal nie ustawiał tutaj pliku cookie, zamiast tego wysyłał wartości zmiennych do serwera SSO.
4. Serwer SSO pobierze wartości, utworzy plik cookie i upuści go w domenie głównej domain.com(aby to przypomnieć my websitei sso serverznajduje się w subdomenie domeny głównej, która również nie znajduje się w Drupal). Następnie witryna Drupal może zalogować się przy użyciu tego pliku cookie.

Wiem, że to trudne pytanie, szukam tylko wskazówek, jak zacząć? jak mówią „nie należy rąbać rdzenia”. Tak więc moje pytania to:

1. Gdzie powinienem znaleźć informacje na temat dogłębnego działania uwierzytelniania Drupal i zarządzania sesjami?
2. Czy istnieje sposób, w jaki mógłbym wywoływać funkcje przy includes/session.incużyciu haków (ponieważ komentarze do funkcji mówią „tylko do użytku wewnętrznego / nie do modyfikacji”)?

UWAGA: Będę używać tej samej metody do rejestracji użytkownika, aby rekord pozostał w centralnej bazie danych serwera SSO. I podczas tego wstawi jakieś śmieciowe hasło dla tego samego użytkownika w bazie danych strony Drupal (ponieważ hasło nie będzie sprawdzane podczas logowania).

Drupal obsługuje zewnętrzne uwierzytelnianie . Istnieje wiele alternatywnych modułów uwierzytelniania dla Drupal, takich jak OpenID (zawarte w rdzeniu), OAuth Connector lub LDAP . Dowiedz się więcej o tym, jak działa uwierzytelnianie Drupal; najlepiej byłoby spojrzeć na moduły OpenID i OAuth, a na podstawowy formularz logowania przesłać wywołanie zwrotne. Ale, AFAIK, zawsze zaczynają normalną sesję Drupal po udanym uwierzytelnieniu.

W celu zarządzania sesjami Drupal podłącza się do obsługi sesji PHP i rejestruje własne procedury obsługi. Samo zaplecze sesji Drupal można podłączyć, możesz ustawić session_inczmienną na ścieżkę pliku, zapewniając alternatywne implementacje funkcji znalezionych w includes/session.inc. Memcache moduł wykorzystać do przechowywania sesji w memcached.

W przypadku odniesień moduł OpenID obsługuje udane uwierzytelnianie, w openid_authentication()którym sam kończy działanie, i wywołuje moduł obsługi formularza logowania użytkownika (tj. user_login_submit()). Sama procedura obsługi przesyłania jest prosta, ładuje pomyślnie uwierzytelnionego użytkownika user_load()do $userzmiennej globalnej , a następnie wywołuje user_login_finalize()sesję obsługi, sygnaturę czasową logowania w usertabeli i wywołuje hook_user_login()implementacje.

Inną opcją jest użycie user_external_login_register()funkcji. Funkcja zaloguje zewnętrznego użytkownika. W razie potrzeby tworzy także lokalnego użytkownika. Jeśli potrzebujesz więcej kontroli nad tworzeniem lokalnego użytkownika, zawsze można użyć user_save(), user_set_authmaps(), user_login_submit()i user_external_load()od was zwyczaj dzwonić, używając user_external_login_register()jako wzorca, co należy zrobić.

user_authenticate () APi może się tu przydać.

3.Za pomocą odpowiedzi zidentyfikuj użytkownika w tabeli użytkowników i utwórz sesję dla tego użytkownika bez sprawdzania hasła (ponieważ oznaczałoby to podwójne uwierzytelnienie). Domyślnie Drupal ustawia plik cookie o nazwie $insecure_session_namezmiennej i wartości $sid. Chcę, aby Drupal nie ustawiał tutaj pliku cookie, zamiast tego wysyłał wartości zmiennych do serwera SSO.

EDYCJA: Gdy serwer SSO powróci z prawdziwym użyciem tego interfejsu API, aby zalogować się do użytkownika, który automatycznie zajmie się Twoimi sesjami. Myślę, że lepiej, jeśli użyjesz go user_authenticate()zamiast tworzyć sesje samodzielnie. Nie powinno to stanowić problemu nawet w przypadku podwójnego uwierzytelnienia, o ile zapewnione jest prawidłowe p-assowrd.

Nie jestem pewien 4. Czy chcesz, aby plik cookie był widoczny w obu domenach? Jeśli tak, to w ustawieniach.php zainicjuj $cookie_domaindomenę. Następnie pliki cookie w podstronie będą dostępne w witrynie nadrzędnej.