web-dev-qa-db-fra.com

Comprendre la gestion de session et l'authentification utilisateur de Drupal

J'ai une exigence où, je dois remplacer l'authentification utilisateur par défaut par l'authentification d'un serveur central, c'est-à-dire un serveur SSO.
En déboguant Drupal j'ai appris que toute la gestion de session se passe dans includes/session.inc fichier. Je veux faire l'authentification comme indiqué dans l'image:

snap

SCÉNARIO: Connexion
Les détails des étapes seraient les suivants:

  1. Remplacez le formulaire de connexion pour soumettre le nom d'utilisateur et le mot de passe au serveur SSO (pas sur Drupal, mais sur .NET).
  2. Authentifier l'utilisateur sur le serveur SSO en utilisant la base de données de ce site; et renvoyer une réponse à une page personnalisée PHP de mon site Web (ou un formulaire par un module?).
  3. À l'aide de la réponse, identifiez l'utilisateur dans la table users et créez une session pour cet utilisateur sans vérifier le mot de passe (car cela signifierait une double authentification) . Par défaut, Drupal définit un cookie avec le nom de $insecure_session_name variable, et avec la valeur $sid. Je veux Drupal ne pas définir le cookie ici, envoyer à la place les valeurs des variables au serveur SSO.
  4. Le serveur SSO prendra les valeurs, créera un cookie et le déposera dans le domaine principal domain.com (pour rappeler aux deux my website et sso server sont sur le sous-domaine du domaine principal, qui n'est pas non plus dans Drupal). Ensuite, le site drupal peut se connecter en utilisant ce cookie.

Je sais que c'est une question difficile, je cherche juste des conseils sur la façon de commencer? comme ils disent "vous ne devriez pas pirater le noyau". Donc, mes questions sont:

  1. Où dois-je chercher pour comprendre comment Drupal et la gestion de session fonctionnent en profondeur?
  2. Existe-t-il un moyen d'appeler les fonctions dans includes/session.inc à l'aide de crochets (comme le dit le commentaire avec les fonctions "pour usage interne uniquement/à ne pas modifier")?

REMARQUE: J'utiliserai la même méthode pour enregistrer l'utilisateur, afin que l'enregistrement reste dans la base de données centrale du serveur SSO. Et pendant cela, un mot de passe indésirable sera inséré pour le même utilisateur dans la base de données du site Drupal) (car le mot de passe ne sera pas vérifié lors de la connexion).

17
AjitS

Drupal prend en charge l'authentification externe . Il existe de nombreux modules d'authentification alternatifs pour Drupal, tels que OpenID (inclus dans le noyau), Connecteur OAuth , ou LDAP . En savoir plus sur le fonctionnement de l'authentification Drupal; le mieux serait de consulter les modules OpenID et OAuth, et de renvoyer le rappel au formulaire de connexion principal. Mais, AFAIK, ils démarrent toujours la session normale Drupal après une authentification réussie.

Pour la gestion de session, Drupal se connecte à PHP gestion de session et enregistre ses propres gestionnaires. Le backend de session Drupal session est lui-même enfichable) , vous pouvez définir la variable session_inc sur le chemin d'un fichier fournissant des implémentations alternatives des fonctions trouvées dans includes/session.inc. Le module memcache l'utilise pour stocker la session dans memcached .

Pour les références, le module OpenID gère l'authentification réussie dans openid_authentication() qui lui-même coupe et appelle le gestionnaire de soumission du formulaire de connexion utilisateur (ie. user_login_submit()). Ce gestionnaire de soumission lui-même est simple, il charge l'utilisateur authentifié avec succès avec user_load() dans la variable globale $user, Puis il appelle user_login_finalize() qui gère la session, horodatage de connexion dans le user table et invoquez les implémentations hook_user_login().

Une autre option consiste à utiliser la fonction user_external_login_register() . La fonction connecte un utilisateur externe. Elle crée également un utilisateur local si nécessaire. Si vous avez besoin de plus de contrôle sur la création d'utilisateurs locaux, vous pouvez toujours utiliser user_save() , user_set_authmaps() , user_login_submit() et user_external_load() de votre appel personnalisé, en utilisant user_external_login_register() comme modèle de ce qui doit être fait.

17
Pierre Buyle

ser_authenticate () APi pourrait être utile ici.

3.À l'aide de la réponse, identifiez l'utilisateur dans le tableau des utilisateurs et créez une session pour cet utilisateur sans vérifier le mot de passe (car cela signifierait double authentification). Par défaut, Drupal définit un cookie avec le nom de la variable $insecure_session_name Et avec la valeur $sid. Je veux Drupal pas pour définir le cookie ici, envoyez plutôt les valeurs des variables au serveur SSO.

EDIT: Une fois que le serveur SSO revient avec vrai, utilisez cette API pour vous connecter à l'utilisateur qui s'occupera automatiquement des sessions pour vous. Je pense que c'est mieux si vous utilisez user_authenticate() au lieu de créer des sessions par vous-même. Cela ne devrait pas poser de problème, même si c'est une double authentification tant que p-assowrd valide est fourni.

Je ne suis pas sûr de 4. Voulez-vous que le cookie soit visible dans les deux domaines? Si c'est le cas, dans settings.php, initialisez $cookie_domain Au domaine. Ensuite, les cookies du sous-site seront disponibles sur le site parent.

1
GoodSp33d