Es probable que ya se enfrente a esto. El personal inicia sesión en Microsoft 365, luego en una herramienta de reservas, luego en RR. HH., luego en una aplicación empresarial y, por último, en la WiFi corporativa, a menudo con un método diferente para cada uno. Un grupo hotelero tiene un conjunto de sistemas en la oficina central y otro en el establecimiento. Un hospital dispone de aplicaciones clínicas, estaciones de trabajo compartidas y acceso inalámbrico segmentado. Un operador de retail tiene personal que se desplaza entre tiendas, tabletas, POS y paneles de control de administración.
Esa combinación genera fricciones rápidamente. Los usuarios olvidan las contraseñas, los equipos de TI restablecen las cuentas y las credenciales de WiFi compartidas permanecen activas mucho después de lo debido. El resultado no es solo un motivo de molestia, sino un control más débil sobre quién puede acceder a qué, desde qué dispositivo y durante cuánto tiempo.
Ahí es donde el single sign-on, o SSO, resulta útil. Si está buscando qué es single sign on, la respuesta corta es sencilla: permite que un usuario se autentique una vez y luego acceda a múltiples sistemas autorizados sin tener que introducir credenciales una y otra vez. La respuesta más útil es operativa. El SSO proporciona a TI una única capa de identidad para el acceso a las aplicaciones y, con el diseño adecuado, también puede dar soporte a la forma en que las personas y los dispositivos se unen a las redes seguras.
El fin del caos de las contraseñas
La mayoría de los entornos empresariales no se volvieron complejos a propósito. Crecieron así. Una aplicación en la nube se convirtió en cinco. Una oficina se convirtió en múltiples sedes. Una red inalámbrica para TI se convirtió en SSIDs independientes para el personal, invitados, contratistas y dispositivos.
Así es como comienza la dispersión de contraseñas. Un miembro del personal puede necesitar correo electrónico, recursos humanos, programación, acceso a archivos, paneles internos y acceso a la red, todo antes de poder realizar un trabajo real. IBM describe el SSO como un esquema en el que los usuarios inician sesión una vez con un único conjunto de credenciales y acceden a múltiples aplicaciones durante la misma sesión, habilitado por una relación de confianza entre los proveedores de servicios y un proveedor de identidad. La descripción general de IBM sobre el inicio de sesión único se ajusta estrechamente a lo que las organizaciones del Reino Unido necesitaron a medida que se aceleraban la adopción de la nube y el trabajo remoto.
Consecuencias de la dispersión de contraseñas en las operaciones
Cuando cada aplicación solicita su propio inicio de sesión, los usuarios empiezan a tomar atajos. Reutilizan contraseñas. Las guardan en los navegadores. Piden a sus compañeros la "contraseña del WiFi del personal" porque es más rápido que esperar a TI.
Para un responsable de TI de una empresa, el control es la máxima prioridad. Los inicios de sesión independientes crean islas de acceso separadas, y esas islas son más difíciles de gobernar cuando las personas cambian de puesto, abandonan la empresa o trabajan en varias ubicaciones.
El caos de las contraseñas rara vez es un único gran fallo. Suele ser el resultado de un centenar de pequeñas decisiones de acceso que nadie puede gestionar de forma constante.
Por qué el SSO cambia las reglas del juego
El SSO reduce la cantidad de contraseñas que los usuarios deben gestionar, lo que mejora la experiencia de inicio de sesión y respalda una seguridad más sólida cuando se combina con una política central y MFA. También se adapta a la realidad de las organizaciones distribuidas donde el personal necesita un único inicio de sesión para el correo electrónico, RR. HH., herramientas de reserva, POS, aplicaciones internas y servicios del sitio.
Esa misma lógica está dando forma ahora al acceso a la red. Si ya está avanzando hacia un acceso basado en la identidad para las aplicaciones, tiene sentido considerar el WiFi sin contraseña como parte del mismo enfoque de diseño, no como un problema independiente.
Comprender el concepto básico de SSO
El SSO traslada la autenticación fuera de cada aplicación individual y la sitúa en un único sistema de identidad de confianza. El usuario inicia sesión una vez, se verifica esa identidad y los servicios conectados aceptan ese resultado en lugar de solicitar otra contraseña.
Esto parece sencillo, pero el valor reside en la arquitectura. Está cambiando el lugar donde reside la confianza.
Las tres partes de todo flujo de SSO
Cada diseño de SSO cuenta con tres participantes, y cada uno tiene una función diferente:
- El usuario desea acceder a una aplicación, servicio o recurso de red.
- El Proveedor de Identidad o IdP verifica la identidad y aplica la política de inicio de sesión. Ejemplos habituales en las organizaciones del Reino Unido son Microsoft Entra ID y Okta.
- El Proveedor de Servicios o SP es el sistema al que el usuario intenta acceder, como Salesforce, una plataforma de reservas, una intranet u otro sistema empresarial.
El punto que a menudo genera confusión es la confianza. La aplicación no necesita recopilar y verificar la contraseña por sí misma. Confía en el IdP para realizar ese trabajo correctamente y luego acepta el resultado.
Qué significa realmente la relación de confianza
Auth0 explica el SSO claramente en términos empresariales: el IdP autentica al usuario una vez y, a continuación, emite un artefacto de sesión o token que los proveedores de servicios de confianza validan para accesos posteriores. En la práctica, se redirige al usuario al IdP, se le autentica allí y se le devuelve a cada aplicación sin que se le vuelvan a solicitar las credenciales. La guía de Auth0 sobre cómo funciona el inicio de sesión único es especialmente relevante en entornos del Reino Unido que utilizan Microsoft Entra ID en sistemas SaaS e internos.
Una forma práctica de interpretarlo es la siguiente:
- Un usuario abre una aplicación.
- La aplicación comprueba si un IdP de confianza ya ha autenticado a ese usuario.
- Si no existe una sesión activa, el usuario inicia sesión con el IdP.
- El IdP confirma la identidad y devuelve una prueba que la aplicación puede validar.
- Otros sistemas conectados pueden aceptar esa misma prueba durante la sesión.
Regla práctica: El SSO no convierte todos los sistemas en una única plataforma. Ofrece a múltiples sistemas un único lugar para verificar la identidad.
Por qué esto es importante fuera de las aplicaciones web
Aquí es también donde el SSO se convierte en algo más que una comodidad de SaaS. Una vez centralizada la identidad, el mismo modelo puede utilizarse para algo más que para las sesiones de navegador. También puede definir la forma en que se controla el acceso a los servicios internos y, con el diseño adecuado, el modo en que los usuarios se unen a la red inalámbrica corporativa.
Eso es importante para las operaciones de TI. Una aplicación financiera, una sesión de VPN y una conexión WiFi para empleados pueden ser servicios diferentes, pero todos comienzan con la misma pregunta: ¿quién es este usuario y se le debe permitir la entrada? Cuando Microsoft Entra ID u Okta responden a esa pregunta de manera constante, la política de acceso resulta más fácil de gestionar tanto en las aplicaciones como en los puntos de entrada a la red.
Para los equipos que todavía utilizan el WiFi del personal con una contraseña compartida, esto representa un cambio importante. En lugar de autenticar un dispositivo con una contraseña que todo el mundo conoce, se autentica a una persona o a un dispositivo gestionado frente a una fuente de identidad de confianza. Esto proporciona un control más estricto, un historial de auditoría más claro y una forma más limpia de revocar el acceso cuando cambian las funciones o finaliza la relación laboral.
Cómo funciona el SSO: los protocolos principales
La experiencia de usuario parece sencilla. Por debajo, el SSO depende de protocolos estándar que permiten a una aplicación confiar en una decisión de identidad tomada en otro lugar.
Para un administrador de TI empresarial, la pregunta práctica no es solo "¿qué es el SSO?" Es "¿cómo acepta un sistema la prueba de otro sistema sin pedirle al usuario que vuelva a iniciar sesión?" La respuesta depende de un pequeño conjunto de protocolos que mueven los datos de identidad entre la aplicación, el proveedor de identidad y, a veces, el propio dispositivo.
Esto resulta relevante más allá de los inicios de sesión en el navegador. El mismo modelo de confianza utilizado para abrir una aplicación SaaS también puede influir en cómo se conectan los usuarios a las VPN, a las redes cableadas y a la WiFi corporativa cuando esas decisiones de acceso están vinculadas a Microsoft Entra ID, Okta u otra fuente de identidad central.
SAML en un lenguaje sencillo
SAML 2.0 sigue siendo habitual en el SSO empresarial, especialmente para plataformas SaaS consolidadas y sistemas de línea de negocio.
SAML funciona pasando declaraciones de identidad de confianza entre la aplicación y el proveedor de identidad. Un usuario intenta abrir una aplicación. La aplicación lo redirige al IdP. El IdP autentica al usuario y devuelve una aserción firmada digitalmente. La aplicación comprueba esa firma, acepta la reclamación de identidad y crea una sesión.
Ese flujo se adapta a entornos donde el navegador realiza la mayor parte del trabajo y la aplicación espera un intercambio formal basado en estándares.
SAML suele ser una opción muy adecuada para:
- SaaS empresarial como aplicaciones de recursos humanos, finanzas o gestión empresarial heredadas
- Flujos de trabajo basados en el navegador donde los usuarios acceden a los sistemas a través de una sesión web
- Aplicación central de políticas cuando el departamento de TI desea un único lugar para controlar la autenticación
OAuth y OIDC explicados de forma sencilla
OAuth 2.0 comenzó como una forma de otorgar acceso limitado a un recurso sin compartir un conjunto completo de credenciales. Por sí mismo, se centra en la autorización.
OpenID Connect, u OIDC, añade identidad sobre OAuth 2.0. Eso proporciona a las aplicaciones modernas una forma estándar de confirmar quién es el usuario y al mismo tiempo utilizar patrones de acceso basados en tokens. Si bien SAML a menudo se adapta al SaaS más antiguo centrado en el navegador, OIDC suele adaptarse mejor a las aplicaciones web más nuevas, aplicaciones móviles y servicios basados en API.
En la práctica, OIDC suele resultar más ágil para los equipos de desarrollo modernos porque los tokens funcionan bien en aplicaciones front-end, servicios back-end y clientes móviles. Para TI, esto significa menos soluciones provisionales complejas cuando la aplicación no es una sesión de navegador tradicional.
OIDC suele ser más adecuado para:
- Aplicaciones en la nube modernas
- Aplicaciones móviles y de página única
- Entornos que hacen un uso intensivo de APIs donde los tokens ya forman parte del diseño
Una breve nota sobre Kerberos
También es posible que oiga hablar de Kerberos en los debates sobre SSO. Kerberos está estrechamente ligado a los entornos tradicionales de Active Directory y a la autenticación local de Windows. Sigue siendo relevante en entornos empresariales internos, especialmente allí donde los dispositivos unidos al dominio y las aplicaciones heredadas siguen siendo habituales.
Dicho esto, muchos proyectos de SSO actuales se centran en la identidad federada en servicios en la nube e híbridos. En esos casos, SAML y OIDC suelen recibir más atención porque se conectan de forma más natural con las plataformas SaaS y los servicios accesibles externamente.
SAML frente a OIDC de un vistazo
| Función | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| Rol principal | Autenticación para aplicaciones web empresariales | Autorización con identidad añadida a través de OIDC |
| Caso de uso común | Aplicaciones SaaS consolidadas y aplicaciones empresariales basadas en navegador | Aplicaciones web modernas, aplicaciones móviles, APIs |
| Formato | Aserciones basadas en XML | Flujos basados en tokens |
| Flujo típico | Redirección al IdP, autenticación, devolución de aserción firmada | Flujo de redirección o de tokens, luego la aplicación utiliza tokens para identidad y acceso |
| Mejor ajuste | Integraciones de SSO empresariales tradicionales | Nuevas arquitecturas nativas de la nube y centradas en aplicaciones |
Lo que realmente importa a un responsable de TI
Los nombres de los protocolos importan menos que las decisiones de diseño. Necesita respuestas claras a cuatro preguntas operativas:
- Qué aplicaciones admiten SAML u OIDC
- Qué IdP actuará como su plano de control central
- Cómo se aplicarán el tiempo de espera de la sesión, MFA y el acceso condicional
- Si el acceso a la red, incluido el WiFi del personal, también debe validar la identidad contra esa misma fuente
Ese último punto es donde el SSO resulta especialmente útil para los equipos de infraestructura. Si su plataforma inalámbrica puede utilizar la misma capa de identidad que su entorno SaaS, la política de acceso se vuelve más coherente desde la página de inicio de sesión hasta el extremo de la red. Esa es una de las razones por las que muchos equipos que analizan los beneficios de single sign-on para el control de acceso y las operaciones también empiezan a buscar la autenticación de WiFi respaldada por identidad, y no solo los inicios de sesión en aplicaciones web.
Evaluación de los beneficios y los riesgos de seguridad
El SSO a menudo se vende como una función de conveniencia para el usuario. Eso es subestimarlo. Si se hace correctamente, es un modelo de control de acceso que puede mejorar la experiencia del usuario y reforzar la seguridad operativa al mismo tiempo.
Okta señala que la ventaja técnica del SSO no es solo la comodidad. Reduce la proliferación de contraseñas y los eventos de inicio de sesión repetidos que aumentan la carga del departamento de soporte técnico y la fricción de los usuarios. La descripción general de Okta sobre la seguridad del inicio de sesión único también destaca un punto que preocupa a los arquitectos: si la sesión del IdP se invalida, las aplicaciones conectadas pueden denegar el acceso en la siguiente comprobación del token.
Dónde se refleja el valor empresarial
El primer beneficio es un acceso más sencillo. Los usuarios inician sesión una vez, empiezan a trabajar antes y dejan de ver la autenticación como un obstáculo diario.
El segundo es un control centralizado más sólido. El departamento de TI puede aplicar MFA, acceso condicional, políticas de sesión y revocación desde una única capa de identidad en lugar de tener que buscar la configuración dentro de cada aplicación.
Un tercer beneficio es una gestión más limpia de las incorporaciones, cambios de puesto y bajas. Cuando la identidad se gestiona de forma centralizada, la incorporación y la desvinculación se vuelven más consistentes. Esa es una de las razones por las que los equipos que exploran los beneficios de single sign-on a menudo conectan los proyectos de SSO con un trabajo de gobernanza de identidad más amplio.
Las compensaciones que debe tomarse en serio
Existe una preocupación real sobre el riesgo de entregar "las llaves del reino". Si un atacante compromete el inicio de sesión principal de un usuario, el radio de impacto puede ser mayor porque una sola cuenta puede dar acceso a muchos sistemas.
También existe un riesgo de resiliencia. Si el IdP no está disponible, el acceso a los servicios conectados puede verse interrumpido. Y la integración no siempre es sencilla. Las aplicaciones más antiguas, los sistemas de nicho y los servicios de red local no siempre encajan de forma limpia en un modelo de SSO moderno.
La pregunta correcta no es si el SSO implica asumir ciertos riesgos. Es si prefiere gestionar esos riesgos de forma centralizada o seguir gestionando docenas de ellos de manera desconectada.
Mitigaciones habituales
Utilice un enfoque estructurado por capas:
- Proteja fuertemente el IdP con MFA, acceso condicional, confianza en el dispositivo y controles de administración sólidos.
- Planifique la resiliencia para que un problema en el IdP no paralice a toda la organización.
- Implemente por fases, empezando por las aplicaciones de alto valor y grupos de usuarios claros.
- Revise el acceso periódicamente para que los permisos obsoletos no se mantengan mucho después de dejar de ser necesarios.
Un despliegue de SSO débil puede centralizar los problemas. Uno sólido centraliza el control.
SSO más allá de las aplicaciones web: acceso a redes y WiFi
La mayoría de los artículos se quedan en el SaaS. Eso es útil, pero incompleto. En entornos reales, el personal no solo necesita acceso a las aplicaciones. Necesitan un acceso seguro a la red cuando llegan a las instalaciones, conectan un portátil gestionado, abren una tableta en una sucursal o se desplazan entre distintas propiedades.
Ahí es donde la conversación sobre el SSO se vuelve más interesante. El mismo proveedor de identidad que gestiona el acceso a Microsoft 365, los sistemas de recursos humanos o los paneles internos también puede convertirse en la fuente de información de referencia para las políticas de autenticación inalámbrica.
Optimal IdM informa que el 52% de los profesionales de TI en América del Norte utilizan SSO para la gestión de identidades en su análisis sobre la adopción del inicio de sesión único. Para las organizaciones del Reino Unido con múltiples sedes o instalaciones, esa madurez es importante porque el personal suele necesitar un acceso seguro a los sistemas compartidos sin tener que iniciar sesión repetidamente.
El SSO de aplicaciones y la identidad de red están relacionados, pero no son idénticos
Un punto habitual de confusión para los lectores es que el SSO para aplicaciones y el acceso a la red basado en la identidad son conceptos relacionados, pero no son el mismo mecanismo.
El SSO de aplicaciones suele significar que el usuario se autentica una vez con un IdP y recibe un token o sesión aceptada por las aplicaciones conectadas. El acceso a la red suele utilizar controles diferentes, como certificados de dispositivo, métodos de autenticación inalámbrica, políticas respaldadas por directorios y comprobaciones de estado o confianza.
Lo que los une es la fuente de identidad. Si Microsoft Entra ID u Okta ya sabe quién es el usuario, a qué grupo pertenece y si su dispositivo está gestionado, puede utilizar ese contexto de identidad para decidir si debe unirse a la red del personal.
Cómo se traduce esto en la red WiFi corporativa
En un diseño maduro, el personal no introduce en absoluto una contraseña de WiFi compartida. Su dispositivo gestionado por la organización está registrado, es de confianza y está asociado a su identidad. Cuando entran en el edificio, el dispositivo se conecta al SSID seguro adecuado mediante una autenticación empresarial basada en certificados o equivalente.
Eso cambia muchas cosas a nivel operativo:
- Las contraseñas compartidas desaparecen, por lo que una credencial filtrada no afecta a toda la red de la plantilla.
- El acceso tiene en cuenta el rol, porque la política puede seguir a los grupos de identidad.
- La revocación es más rápida, porque cuando cambia el acceso al directorio, el acceso a la red puede cambiar con él.
- El roaming se facilita, especialmente en entornos de múltiples sedes donde los usuarios esperan la misma experiencia en todas partes.
Por qué esto es importante en el sector de la hostelería, el comercio minorista y la sanidad
Estos sectores están llenos de casos excepcionales. Tienen trabajadores por turnos, dispositivos compartidos, personal de agencias, equipos itinerantes y una mezcla constante de necesidades de acceso corporativo, semicorporativo y de invitados.
Un grupo hotelero puede querer que una sola identidad del personal controle el acceso al PMS, las aplicaciones de back-office y el WiFi interno seguro en todas las propiedades. Una cadena de tiendas puede querer que los dispositivos de mano gestionados se conecten automáticamente al WiFi de la tienda mientras el tráfico de invitados permanece aislado. Un proveedor de atención médica puede desear una separación más sólida entre los usuarios clínicos, los visitantes y los dispositivos conectados.
Aquí es también donde entran en juego las soluciones de control de acceso a la red. Ayudan a extender la política de identidad desde la capa de aplicación hacia la capa de red.
Dónde encaja Purple
Una opción práctica es Purple, que admite redes basadas en la identidad para el personal y entornos multi-inquilino, incluyendo integraciones con Microsoft Entra ID, Google Workspace y Okta para un acceso seguro sin depender de contraseñas compartidas. Ese tipo de enfoque es de gran utilidad cuando se desea que la identidad de la aplicación y la identidad de la red funcionen desde la misma fuente de información única.
Casos de uso prácticos de SSO en su sector
La forma más sencilla de ver el valor del SSO es fijarse en el trabajo diario, no en los diagramas de arquitectura.
Hostelería
Un responsable de operaciones de un hotel empieza el día en un establecimiento y lo termina en otro. Necesita acceder a la planificación, al sistema de gestión hotelera, a documentos compartidos y al WiFi interno en ambas ubicaciones.
Con SSO, esa identidad les acompaña. Inician sesión una vez y los sistemas aprobados reconocen esa sesión. Si la organización también vincula el acceso a la red con la misma fuente de identidad, su dispositivo gestionado se conecta a la WiFi del personal sin necesidad de que nadie envíe la última contraseña por mensaje de texto al responsable de turno.
Retail
Un gerente regional entra en una tienda con una tableta. Necesita acceder de inmediato a los paneles de ventas, herramientas de inventario y aplicaciones de comunicación interna.
En una configuración fragmentada, cada parada puede suponer otra solicitud de inicio de sesión, otra contraseña caducada o una llamada más al servicio de asistencia. En un modelo basado en la identidad, la tableta se autentica de forma limpia, el acceso refleja el rol del usuario y el personal de la tienda no tiene que compartir credenciales locales para realizar su trabajo.
Un buen SSO no hace que el acceso sea invisible. Hace que el acceso legítimo sea predecible.
Sanidad
Un profesional clínico comienza un turno y necesita un acceso rápido y controlado a los sistemas principales. Puede que tenga que moverse entre estaciones de trabajo, dispositivos compartidos y segmentos de red restringidos durante el día.
Aquí, el SSO ayuda a reducir los inicios de sesión repetidos en las aplicaciones autorizadas, mientras que los controles de red basados en la identidad ayudan a garantizar que los usuarios y dispositivos adecuados se conecten a los entornos inalámbricos correctos. Esa separación es importante. El acceso clínico, el acceso de invitados y el acceso de dispositivos no deben regirse de la misma manera.
Propiedades multiinquilino y campus
En residencias de estudiantes, centros de negocios y propiedades de uso mixto, el personal y los residentes suelen coexistir en la misma infraestructura física, pero nunca deberían compartir el mismo modelo de acceso.
El personal puede necesitar sistemas del edificio, herramientas de soporte y aplicaciones de administración interna. Los residentes o inquilinos necesitan una conectividad fiable, pero no acceso a las plataformas operativas. En este contexto, el diseño de la identidad es lo que más importa. El SSO puede dar soporte al acceso del personal, mientras que las políticas de identidad de red independientes mantienen aislado el tráfico de inquilinos e invitados.
Implementación y mejores prácticas de SSO
Un proyecto de SSO de éxito comienza con una decisión: elegir el proveedor de identidad que actuará como plano de control. Para muchas organizaciones, ese proveedor es Microsoft Entra ID o Okta, ya que esas plataformas ya están muy integradas con el ciclo de vida del usuario, la MFA y las políticas de dispositivos.
El despliegue debe ser progresivo. Comience con las aplicaciones más importantes y los grupos de usuarios que más se puedan beneficiar. Elimine las cuentas duplicadas, defina correctamente los grupos de roles y pruebe el comportamiento de las sesiones antes de ampliar el alcance.
Los controles que más importan
Unas pocas prácticas marcan la diferencia entre una demostración atractiva y una implementación duradera:
- Exigir MFA en el punto de inicio de sesión principal. Si un solo inicio de sesión puede proporcionar acceso a muchos recursos, ese inicio de sesión necesita una protección más sólida.
- Crear procesos de baja basados en la revocación inmediata. La identidad centralizada solo ayuda si los cambios de cuenta se propagan rápidamente.
- Revisar el acceso por rol. El SSO puede hacer que el exceso de privilegios sea más fácil de pasar por alto si nadie comprueba quién sigue teniendo acceso.
- Planificar ante interrupciones del IdP. Sepa qué ocurre si su servicio de identidad no está disponible y qué sistemas necesitan una gestión de contingencia.
Sepa cuándo el SSO no es la herramienta adecuada
Este punto se pasa por alto en muchas explicaciones genéricas. OneLogin señala una creciente distinción entre el SSO de la fuerza laboral y el acceso de invitados o dispositivos en implementaciones del mundo real, y plantea una pregunta útil para el comprador en su explicación de cómo funciona el inicio de sesión único: ¿cuándo es el SSO la herramienta equivocada y cuándo debería aplicarse la identidad al acceso a la red en lugar de al inicio de sesión de la aplicación?
Esto es importante en el diseño de redes WiFi. El personal a menudo debe utilizar un acceso basado en políticas y vinculado a la identidad. Los invitados suelen necesitar algo más ligero, sencillo y separado. Intentar forzar cada problema de acceso a través del SSO de la plantilla genera fricciones innecesarias.
Si está evaluando el SSO como parte de una estrategia de acceso más amplia, incluya las aplicaciones, el WiFi del personal, el registro de invitados, los dispositivos compartidos y los flujos de trabajo de revocación en la misma conversación. Ahí es donde suelen aparecer los mayores beneficios operativos.
Si está rediseñando el acceso en todas las aplicaciones, el WiFi del personal, el registro de invitados o las redes multi-inquilino, vale la pena echar un vistazo a Purple. Ofrece redes basadas en la identidad que pueden funcionar con plataformas como Microsoft Entra ID, Okta y Google Workspace, ayudando a los equipos a sustituir las contraseñas compartidas y los incómodos Captive Portal por un acceso controlado para el personal, los invitados y los residentes.
