Estoy instalando un inicio de sesión de CMS que se comparte entre dos organizaciones, una es un blog para la comunidad diseñado para facilitar el inicio de sesión y la otra es una aplicación de PHP para el personal para una organización no lucrativa relacionada, para realizar un seguimiento de la membresía, etc. Una base de datos personalizada para el mantenimiento de registros de negocios.
La composición de los inicios de sesión del personal es un subconjunto variable de los usuarios que son usuarios conocidos de CMS, que tienen inicios de sesión reconocidos. La composición de los usuarios del blog 100% de los usuarios de CMS. (Al igual que los usuarios de Stack Exchange frente a los usuarios de Stack Exchange con acceso a la cuenta en Server Fault). Además, el blog está dirigido a un grupo diverso de usuarios, algunos de los cuales no están en Facebook, etc. y otros están solo en Facebook, etc., por lo que cualquier cosa que no sea un inicio de sesión compartido serviría como una barrera .
Para evitar que las cuentas extranjeras pirateadas obtengan automáticamente acceso al personal, los usuarios conocidos recibirán privilegios de personal en el lado de la aplicación empresarial a través de una lista blanca de privilegios de usuario de usuarios conocidos con > 1 privilegios (0 = invitado no registrado) junto con un inicio de sesión secundario OAuth (ID de personal) dentro del módulo OpenID de la aplicación cliente. El inicio de sesión secundario de OAuth sería una búsqueda en la aplicación por usuario una vez que se haya establecido la identidad de OpenID. La idea es que la mayoría de los usuarios ya habrían iniciado sesión en el sitio principal (blog) y, por lo tanto, serán reconocidos.
Nuestro soporte actual de dev / tech está familiarizado con HybridAuth y lo recomienda altamente como un complemento para que los módulos PHP personalizados interactúen con las cuentas de inicio de sesión de CMS existentes y también con Facebook, etc. utilizando OAuth. HybridAuth también tiene provisión para OpenID, pero él solo está familiarizado con su uso para OAuth.
Según mi lectura, preferiría usar OpenID, ya que eso haría que la aplicación PHP sea reutilizable y no dependiente de una instancia de Drupal de un solo cliente para los inicios de sesión.
La instancia de la aplicación aún podría estar vinculada a una biblioteca Drupal no específica de la instancia para la configuración del CMS.
Sin embargo, mi preferencia se basa en los siguientes supuestos:
-
Que HybridAuth es capaz de implementar una versión segura y fácil de usar de OpenID. Ya que HybridAuth aparentemente tiene una buena biblioteca OAuth y es compatible con OpenID, ¿es un buen sustituto para OpenID Connect también? ¿Tiene una funcionalidad similar de OpenID?
-
¿Que OpenID / Connect ahora se puede configurar de una forma fácil de usar para permitir la identificación de correo electrónico por emisor? (Lo limitaría a emisores como Google y Facebook que permiten el correo electrónico, o combinaciones de contraseña de correo electrónico, a usuarios de identificación única, y configuran el inicio de sesión local en consecuencia).
-
Ese OpenID / Connect ahora se puede configurar de una manera fácil de usar para permitir el inicio de sesión fuera del sitio a través del emisor (por ejemplo, "iniciar sesión con Google o Facebook") dentro del marco o sin tener que pasar por múltiples páginas , preferiblemente sin tener que abandonar el sitio principal.
-
Que Drupal o un CMS similar alojado en el cliente se puede usar como OpenID emisor para inicios de sesión locales directamente o en un sitio asociado, como lo hace Stack Exchange (supongo). No sé cómo funcionan los inicios de sesión estándar de Drupal. ¿Es como un ID de Drupal universal, o es específico del sitio y solo una capa de db? ¿Drupal solo admite el cliente OpenID inicio de sesión , no el emisor de OpenID? ¿El emisor de Drupal es específico del sitio, si existe, y está basado en la url del emisor de Drupal?
-
Que HybridAuth y / o OpenID Connect permite conectarse a través de OpenID existente (o con un solo clic si ya ha iniciado sesión con el emisor) y luego OAuth a los servicios (solo para el personal).
-
Que HybridAuth y / o Drupal tiene un módulo integrado OpenID Issuer para el sitio principal que no requiere un PhD. en PHP para instalar.
¿Uno o más de estos supuestos son incorrectos? ¿O no importa y debería usar OAuth solamente? (Supongo que OAuth requiere registrar cada instancia de la aplicación con el CMS del cliente y los proveedores de redes sociales elegidos; tenga en cuenta que la aplicación se encuentra en un dominio diferente pero relacionado al blog en sí).