Azure App Service Container

Esegui il deployment di FoxIDs nel tuo tenant Azure come tuo cloud privato.

Una installazione FoxIDs è autonoma, ha poche dipendenze esterne e può ottenere un uptime molto elevato con poco sforzo. FoxIDs viene aggiornato aggiornando le due docker images www.foxids.com/foxids:x.x.x e www.foxids.com/foxidscontrol:x.x.x a una nuova versione. Le nuove release FoxIDs sono backward compatible. Controlla le release notes prima di aggiornare. Li puoi anche trovare la versione corrente della Docker image.

Per accedere alle release FoxIDs e richiesta una licenza valida. Da li puoi generare un secret per autenticarti con il Docker image registry su www.foxids.com, che usa autenticazione Basic.

FoxIDs viene distribuito nel resource group FoxIDs, nome facoltativo, dove devi avere il ruolo Owner oppure Contributor e User Access Administrator a livello di subscription oppure di resource group.

Deploy to Azure

Puoi fare un small deployment to Azure con basso consumo di risorse a un prezzo Azure di circa EUR 80 a EUR 100 al mese.

Il deployment del container Azure include:

• Due App Services, una per il sito FoxIDs e una per il sito FoxIDs Control, Client e API. Entrambe le App Services sono ospitate nello stesso Linux App Service plan.
• FoxIDs viene distribuito con due docker images www.foxids.com/foxids:x.x.x e www.foxids.com/foxidscontrol:x.x.x.
• Key Vault. Certificati e segreti vengono salvati e gestiti in Key Vault.
• Cosmos DB. Contiene tutti i dati inclusi tenant, ambienti e utenti. Cosmos DB e un database NoSQL e i dati vengono salvati in documenti JSON.
• Redis cache. Mantiene sequenze, ad esempio login e logout, cache dati per migliorare le prestazioni e gestire contatori per proteggere l'autenticazione da vari attacchi.
• Application Insights e Log Analytics workspace. I log vengono inviati ad Application Insights e interrogati in Log Analytics workspace.
• Rete virtuale (VNet) con subnet.
  • Subnet per App services, Cosmos DB e Key Vault.
  • Subnet con Private Link verso Redis.

Un'altra opzione alternativa e distribuire FoxIDs con Kubernetes (K8s) in Azure Kubernetes Service, AKS.

Parameters in ARM template

Imposta i parametri durante il deployment, oppure scarica i template ARM qui e aggiorna i parametri in azuredeploy.json oppure azuredeploy-small.json:

• appServicePlanSize - Dimensione dell'istanza dell'App Service plan. Il default è P1V3 in azuredeploy.json e P0V3 in azuredeploy-small.json.
• appServicePlanSku - Pricing tier dell'App Service plan. Il default è Standard.
• keyVaultSkuName - SKU di Key Vault. Il default è Standard.
• sendgridFromEmail - Indirizzo email mittente SendGrid opzionale.
• sendgridApiKey - API key SendGrid opzionale.
• foxidsVersion - Versione della Docker image FoxIDs.
• dockerRegistryCustomerId - Username, il tuo customer ID.
• dockerRegistryPullSecret - Password, il tuo pull secret.

Puoi anche distribuire dalla command line fornendo direttamente i parametri. Lo username è il tuo customer ID e la password è il tuo pull secret:

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

Send emails with Sendgrid or SMTP

FoxIDs supporta l'invio di email con SendGrid e SMTP come email provider. FoxIDs supporta anche l'invio di messaggi SMS con provider SMS configurati.

First login and admin users

Dopo il deployment riuscito apri FoxIDs Control Client su https://foxidscontrolxxxxxxxxxx.azurewebsites.net, il servizio app service che inizia con foxidscontrol, che ti porta al tenant master.

L'utente admin predefinito e admin@foxids.com con password FirstAccess!, ti viene richiesto di cambiare la password al primo login.

Facoltativamente vai alla scheda Users e crea altri utenti admin e assegna agli utenti il role admin con valore foxids:tenant.admin.

In generale non dovresti modificare la configurazione delle application registrations e dei metodi di autenticazione nel tenant master, a meno che tu non sia sicuro di quello che stai facendo. Invece continua con il passo successivo per creare un tenant main.

Create main tenant

Crea un tenant main per i tuoi ambienti.

Considera i custom domains prima di creare il tenant main.

Fai clic su New Tenant e crea il tenant main.

Accedi al tenant main dove puoi iniziare a configurare le tue applications e i tuoi authentication methods.

Custom domains

I custom domains sono configurati con custom primary domains e un custom domain sul tenant main.

Custom primary domains

I primary domains dei siti FoxIDs e FoxIDs Control possono essere personalizzati. I nuovi primary custom domains possono essere configurati sulle App Services oppure usando un reverse proxy.

Importante: cambia il primary domain prima di aggiungere tenant.

Domains:

• Il default domain del sito FoxIDs e https://foxidsxxxx.azurewebsites.net, che puo essere cambiato in un primary custom domain, ad esempio https://somedomain.com oppure https://id.somedomain.com
• Il default domain del sito FoxIDs Control e https://foxidscontrolxxxx.azurewebsites.net, che puo essere cambiato in un primary custom domain, ad esempio https://control.somedomain.com

Il sito FoxIDs supporta un primary domain e piu custom domains collegati a tenant diversi dal tenant master. Il sito FoxIDs Control supporta solo un primary domain.

Configura nuovi primary custom domains:

1. Accedi a FoxIDs Control Client usando il primary domain predefinito, vecchio. Seleziona la scheda Applications, poi fai clic su OpenID Connect - foxids_control_client e su Show advanced.

   • Aggiungi il nuovo primary custom domain URL del sito FoxIDs Control alla lista Allow CORS origins senza slash finale.
   • Aggiungi i redirect URI di login e logout del nuovo primary custom domain del sito FoxIDs Control Client alla lista Redirect URIs, includendo /master/authentication/login_callback e /master/authentication/logout_callback con slash finale.

   Se hai aggiunto tenant prima di cambiare il primary domain, la configurazione OpenID Connect - foxids_control_client deve essere eseguita in ogni tenant.

2. I custom primary domains sono configurati su ciascuna App Service oppure usando un reverse proxy. A seconda del reverse proxy che stai usando potresti dover configurare i domains anche su ciascuna App Service:

   • Se configurato sulle App Services: aggiungi i custom primary domains nel portale Azure nella FoxIDs App Service e nella FoxIDs Control App Service sotto la scheda Custom domains facendo clic sul link Add custom domain.
   • Se configurato sul reverse proxy: i custom primary domains vengono esposti tramite il reverse proxy.

3. Poi configura i nuovi primary custom domains del sito servizio FoxIDs nella FoxIDs App Service sotto la scheda Environment variables:

   • L'impostazione Settings__FoxIDsEndpoint viene cambiata nel nuovo primary custom domain del sito FoxIDs.

4. E configura i nuovi primary custom domains del sito servizio FoxIDs e del sito FoxIDs Control nella FoxIDs Control App Service sotto la scheda Environment variables:

   • L'impostazione Settings__FoxIDsEndpoint viene cambiata nel nuovo primary custom domain del sito FoxIDs.
   • L'impostazione Settings__FoxIDsControlEndpoint viene cambiata nel nuovo primary custom domain del sito FoxIDs Control.

Custom domain on main tenant

Puoi ottenere un URL piu corto e pulito in cui l'elemento tenant viene rimosso dall'URL. Questo avviene configurando il primary custom domain del sito FoxIDs sul tenant main come custom domain.

I custom domains sono supportati se il sito FoxIDs e dietro un reverse proxy che puo fare domain rewrite.
In alternativa, FoxIDs supporta i custom domains leggendo l'HTTP request domain e usando il domain come custom domain se l'impostazione Setting__RequestDomainAsCustomDomain e impostata su true nelle Environment variables della FoxIDs App Service. In questo caso la FoxIDs App Service deve essere configurata con il custom domain.

Il domain viene configurato sul tenant main e marcato come verificato nel tenant master.

Reverse proxy

Si raccomanda di collocare sia la FoxIDs Azure App service sia la FoxIDs Control Azure App service dietro un reverse proxy.

Azure Front Door

Azure Front Door puo essere configurato come reverse proxy. Azure Front Door riscrive i domains per impostazione predefinita.

NON abilitare la cache. L'header Accept-Language non viene inoltrato se la cache e abilitata. L'header e richiesto da FoxIDs per supportare le culture.

Configurazione:

• Aggiungi un endpoint Azure Front Door sia per la FoxIDs App Service sia per la FoxIDs Control App Service
• Nella sezione Networking delle App Services abilita la restrizione di accesso per consentire traffico solo da Azure Front Door
• Aggiungi l'impostazione Settings__TrustProxyHeaders con valore true nelle Environment variables della FoxIDs App Service
• Disabilita Session affinity
• Facoltativamente configura policy WAF

Alternative reverse proxy

Facoltativamente puoi selezionare un reverse proxy alternativo.

Restrict access
Facoltativamente limita l'accesso se stai usando un reverse proxy diverso da Azure Front Door.

Sia il sito FoxIDs sia il sito FoxIDs Control possono limitare l'accesso in base all'header HTTP X-FoxIDs-Secret.
La restrizione di accesso viene attivata aggiungendo un secret con nome Settings--ProxySecret in Key Vault.

1. Concedi al tuo indirizzo IP l'accesso tramite il firewall di Key Vault

2. Concedi al tuo utente i permessi List e Set nelle Access policies.

3. Aggiungi il secret Settings--ProxySecret

4. Dopo una configurazione riuscita, rimuovi il tuo indirizzo IP e i permessi.

Le App Services devono essere riavviate per leggere il secret.

Dopo che il reverse proxy secret e stato configurato in Key Vault, il reverse proxy deve aggiungere l'header HTTP X-FoxIDs-Secret in tutte le chiamate backend a FoxIDs per ottenere accesso.

Specify default page

Una default page alternativa puo essere configurata per il sito FoxIDs usando l'impostazione Settings__WebsiteUrl con ad esempio il valore https://www.foxidsxxxx.com nelle Environment variables della FoxIDs App Service.

Troubleshooting deployment errors

Key Vault soft deleted

Se hai eliminato un deployment precedente, il Key Vault viene solo soft deleted e continua a esistere con lo stesso nome per alcuni mesi. In questo caso potresti riscontrare un errore ConflictError con il messaggio Exist soft deleted vault with the same name..

La soluzione e eliminare definitivamente, purge, il vecchio Key Vault, che rilascera il nome.