Azure App Service Container

Implemente FoxIDs en su tenant de Azure como su propia nube privada.

Una instalación de FoxIDs es como un bucket, no hay dependencias externas y es fácil lograr una disponibilidad muy alta con poco esfuerzo. FoxIDs se actualiza actualizando las dos imágenes Docker www.foxids.com/foxids:x.x.x y www.foxids.com/foxidscontrol:x.x.x a una nueva versión. Las nuevas versiones de FoxIDs son backward compatible. Revise las notas de versión antes de actualizar. Allí también puede encontrar la versión actual de la imagen Docker.

Se requiere una licencia válida para acceder a las versiones de FoxIDs. Desde allí, puede generar un secret para autenticarse en el registro de imágenes Docker en www.foxids.com, que usa autenticación Basic.

FoxIDs se implementa en el grupo de recursos FoxIDs (nombre opcional) donde necesita ser Owner o Contributor y User Access Administrator ya sea a nivel de suscripción o de grupo de recursos.

Implementar en Azure

Puede hacer un despliegue pequeño en Azure con bajo consumo de recursos a un costo de Azure de alrededor de €80 a €100 por mes.

La implementación de contenedor en Azure incluye:

• Dos App Services, uno para el sitio FoxIDs y otro para el sitio FoxIDs Control (Cliente y API). Ambos App Services están alojados en el mismo plan App Service Linux.
• FoxIDs se implementa con dos imágenes Docker www.foxids.com/foxids:x.x.x y www.foxids.com/foxidscontrol:x.x.x.
• Key Vault. Los certificados y secretos se guardan y se administran en Key Vault.
• Cosmos DB. Contiene todos los datos, incluidos tenants, entornos y usuarios. Cosmos DB es una base de datos NoSQL y los datos se guardan en documentos JSON.
• Caché Redis. Mantiene secuencias (p. ej., login y logout), caché de datos para mejorar el rendimiento y maneja contadores para asegurar la autenticación contra diversas ataques.
• Application Insights y Log Analytics workspace. Los logs se envían a Application Insights y se consultan en Log Analytics workspace.
• VLAN con subredes.
  • Subred para App Services, Cosmos DB y Key Vault.
  • Subred con Private Link a Redis.

Otra alternativa es implementar FoxIDs con Kubernetes (K8s) en Azure Kubernetes Service (AKS).

Parámetros en ARM template

Configure los parámetros durante el despliegue, o descargue los ARM templates aquí y actualice los parámetros en azuredeploy.json o azuredeploy-small.json:

• foxidsVersion - Versión de FoxIDs
• dockerRegistryCustomerId - Nombre de usuario, su ID de cliente
• dockerRegistryPullSecret - Contraseña, su pull secret

También puede desplegar desde la línea de comandos proporcionando los parámetros directamente. El nombre de usuario es su ID de cliente y la contraseña es su pull secret:

az deployment group create --resource-group FoxIDs --template-file azuredeploy.json --parameters foxidsVersion=<foxids-version> dockerRegistryCustomerId=<customer-id> dockerRegistryPullSecret=<pull-secret>

Enviar correos con Sendgrid o SMTP

FoxIDs admite el envío de correos con SendGrid y SMTP como proveedor de correo.

Primer inicio de sesión y usuarios administradores

Después de implementar correctamente, abra FoxIDs Control Client en https://foxidscontrolxxxxxxxxxx.azurewebsites.net (el app service que comienza con foxidscontrol...) lo que le llevará al tenant master.

El usuario admin predeterminado es admin@foxids.com con contraseña FirstAccess! (debe cambiar la contraseña en el primer inicio de sesión)

Opcionalmente navegue a la pestaña Users y cree más usuarios administradores y otorgue a los usuarios el role admin con el valor foxids:tenant.admin.

Por lo general, no debe cambiar la configuración de registros de aplicaciones y métodos de autenticación en el tenant master, a menos que esté seguro de lo que está haciendo. En su lugar, continúe con el siguiente paso para crear un tenant main.

Crear tenant principal

Cree un tenant main para sus entornos.

Considere los dominios personalizados antes de crear el tenant main.

Haga clic en New Tenant y cree el tenant main.

Inicie sesión en el tenant main donde puede comenzar a configurar sus aplicaciones y métodos de autenticación.

Dominios personalizados

Los dominios personalizados se configuran con dominios primarios personalizados y un dominio personalizado en el tenant principal.

Dominios primarios personalizados

Los dominios primarios de los sitios FoxIDs y FoxIDs Control se pueden personalizar. Los nuevos dominios primarios personalizados se pueden configurar en los App Services o usando un reverse proxy.

Importante: cambie el dominio primario antes de agregar tenants.

Dominios:

• El dominio predeterminado del sitio FoxIDs es https://foxidsxxxx.azurewebsites.net y se puede cambiar a un dominio primario personalizado como, por ejemplo, https://somedomain.com o https://id.somedomain.com
• El dominio predeterminado del sitio FoxIDs Control es https://foxidscontrolxxxx.azurewebsites.net y se puede cambiar a un dominio primario personalizado como, por ejemplo, https://control.somedomain.com

El sitio FoxIDs admite un dominio primario y múltiples dominios personalizados que se conectan a tenants distintos del tenant master. El sitio FoxIDs Control solo admite un dominio primario.

Configurar nuevos dominios primarios personalizados:

1. Inicie sesión en FoxIDs Control Client usando el dominio primario predeterminado/antiguo. Seleccione la pestaña Applications, luego haga clic en OpenID Connect - foxids_control_client y haga clic en Show advanced.

   • Agregue la nueva URL de dominio primario personalizado del sitio FoxIDs Control a la lista Allow CORS origins sin barra final.
   • Agregue las URI de redirección de inicio y cierre de sesión del sitio FoxIDs Control Client para el nuevo dominio primario personalizado a la lista Redirect URIs, incluyendo /master/authentication/login_callback y /master/authentication/logout_callback.

   Si ha agregado tenants antes de cambiar el dominio primario, la configuración OpenID Connect - foxids_control_client debe realizarse en cada tenant.

2. Los dominios primarios personalizados se configuran en cada App Service o usando un reverse proxy. Dependiendo del reverse proxy que use, puede que también necesite configurar los dominios en cada App Service:

   • Si se configuran en App Services: agregue los dominios primarios personalizados en el portal de Azure en el App Service FoxIDs y el App Service FoxIDs Control en la pestaña Custom domains haciendo clic en el enlace Add custom domain.
   • Si se configuran en el reverse proxy: los dominios primarios personalizados se exponen a través del reverse proxy.

3. Luego configure los nuevos dominios primarios personalizados del sitio FoxIDs en el App Service FoxIDs en la pestaña Environment variables:

   • El ajuste Settings__FoxIDsEndpoint se cambia al nuevo dominio primario personalizado del sitio FoxIDs.

4. Y configure los nuevos dominios primarios personalizados de los sitios FoxIDs y FoxIDs Control en el App Service FoxIDs Control en la pestaña Environment variables:

   • El ajuste Settings__FoxIDsEndpoint se cambia al nuevo dominio primario personalizado del sitio FoxIDs.
   • El ajuste Settings__FoxIDsControlEndpoint se cambia al nuevo dominio primario personalizado del sitio FoxIDs Control.

Dominio personalizado en el tenant principal

Puede lograr una URL más corta y más bonita donde el elemento tenant se elimina de la URL. Configurando el dominio primario personalizado del sitio FoxIDs en el tenant principal como un dominio personalizado.

Los dominios personalizados se admiten si el sitio FoxIDs está detrás de un reverse proxy que puede reescribir dominios. O alternativamente, FoxIDs admite dominios personalizados leyendo el dominio de la solicitud HTTP y usando el dominio como dominio personalizado si la configuración Setting__RequestDomainAsCustomDomain se establece en true en las Environment variables del App Service de FoxIDs. El App Service de FoxIDs debe configurarse con el dominio personalizado en este caso.

El dominio se configura en el tenant main y se marca como verificado en el tenant master.

Reverse proxy

Se recomienda colocar tanto el App Service de Azure de FoxIDs como el App Service de Azure de FoxIDs Control detrás de un reverse proxy.

Azure Front Door

Azure Front Door se puede configurar como reverse proxy. Azure Front Door reescribe dominios por defecto.

NO habilite el caché. El encabezado Accept-Language no se reenvía si el caché está habilitado. El encabezado es requerido por FoxIDs para admitir culturas.

Configuración:

• Agregue un endpoint de Azure Front Door para el App Service FoxIDs y el App Service FoxIDs Control
• En la sección Networking de los App Services, habilite la restricción de acceso para permitir solo tráfico desde Azure Front Door
• Agregue la configuración Settings__TrustProxyHeaders con el valor true en las Environment variables del App Service de FoxIDs
• Deshabilite Session affinity
• Opcionalmente configure políticas WAF

Reverse proxy alternativo

Puede optar por un reverse proxy alternativo.

Restringir acceso Opcionalmente restrinja el acceso si usa un reverse proxy distinto de Azure Front Door.

Los sitios FoxIDs y FoxIDs Control pueden restringir el acceso basado en el encabezado HTTP X-FoxIDs-Secret. La restricción de acceso se activa agregando un secreto con el nombre Settings--ProxySecret en Key Vault.

1. Conceda acceso a su IP a través del firewall de Key Vault

2. Conceda a su usuario permisos List y Set en Access policies.

3. Agregue el secreto Settings--ProxySecret

4. Después de configurar correctamente, elimine su IP y permisos.

Los App Services deben reiniciarse para leer el secreto.

Después de configurar el secreto del reverse proxy en Key Vault, el reverse proxy debe agregar el encabezado HTTP X-FoxIDs-Secret en todas las llamadas back-end a FoxIDs para obtener acceso.

Especificar página predeterminada

Se puede configurar una página predeterminada alternativa para el sitio FoxIDs usando la configuración Settings__WebsiteUrl con, por ejemplo, el valor https://www.foxidsxxxx.com en las Environment variables del App Service de FoxIDs.

Solución de problemas de errores de implementación

Key Vault eliminado de forma lógica

Si ha eliminado una implementación previa, el Key Vault solo se elimina de forma lógica y aún existe con el mismo nombre durante algunos meses. En este caso puede experimentar un 'ConflictError' con el mensaje de error 'Exist soft deleted vault with the same name.'.

La solución es eliminar (purgar) el Key Vault antiguo, lo que liberará el nombre.