Azure App Service Container

Faca deployment do FoxIDs no seu tenant Azure como a sua cloud privada.

Uma instalação FoxIDs é autónoma, tem poucas dependências externas e consegue obter um uptime muito elevado com pouco esforço. O FoxIDs e atualizado atualizando as duas docker images www.foxids.com/foxids:x.x.x e www.foxids.com/foxidscontrol:x.x.x para uma nova versao. As novas releases do FoxIDs sao backward compatible. Reveja as release notes antes de atualizar. Tambem pode encontrar ai a versao atual da Docker image.

E necessaria uma licenca valida para aceder as releases do FoxIDs. A partir dai, pode gerar um secret para autenticar no Docker image registry em www.foxids.com, que usa autenticacao Basic.

O FoxIDs e implementado no resource group FoxIDs, nome opcional, onde precisa de ser Owner ou Contributor e User Access Administrator ao nivel da subscription ou do resource group.

Deploy to Azure

Pode fazer um small deployment to Azure com baixo consumo de recursos a um preco Azure de cerca de EUR 80 a EUR 100 por mes.

O deployment do container Azure inclui:

Duas App Services, uma para o site FoxIDs e outra para o site FoxIDs Control, Client e API. Ambas as App Services estao alojadas no mesmo Linux App Service plan.
O FoxIDs e distribuido com duas docker images www.foxids.com/foxids:x.x.x e www.foxids.com/foxidscontrol:x.x.x.
Key Vault. Certificados e secrets sao guardados e geridos no Key Vault.
Cosmos DB. Contem todos os dados incluindo tenants, ambientes e utilizadores. O Cosmos DB e uma base de dados NoSQL e os dados sao guardados em documentos JSON.
Redis cache. Mantem sequencias, por exemplo login e logout, cache de dados para melhorar o desempenho e gerir contadores para proteger a autenticacao contra varios ataques.
Application Insights e Log Analytics workspace. Os logs sao enviados para Application Insights e consultados no Log Analytics workspace.
Rede virtual (VNet) com subnets.
- Subnet para App services, Cosmos DB e Key Vault.
- Subnet com Private Link para Redis.

Outra opcao alternativa e fazer deployment do FoxIDs com Kubernetes (K8s) no Azure Kubernetes Service, AKS.

Parameters in ARM template

Defina os parametros durante o deployment, ou descarregue os templates ARM aqui e atualize os parametros em azuredeploy.json ou azuredeploy-small.json:

appServicePlanSize - Tamanho da instancia do App Service plan. O valor por defeito e P1V3 em azuredeploy.json e P0V3 em azuredeploy-small.json.
appServicePlanSku - Escalao de preco do App Service plan. O valor por defeito e Standard.
keyVaultSkuName - SKU do Key Vault. O valor por defeito e Standard.
sendgridFromEmail - Endereco de email remetente SendGrid opcional.
sendgridApiKey - API key SendGrid opcional.
foxidsVersion - Versao da Docker image FoxIDs.
dockerRegistryCustomerId - Username, o seu customer ID.
dockerRegistryPullSecret - Password, o seu pull secret.

Tambem pode fazer deployment a partir da command line fornecendo os parametros diretamente. O username e o seu customer ID e a password e o seu 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

O FoxIDs suporta o envio de emails com SendGrid e SMTP como email provider. O FoxIDs tambem suporta o envio de mensagens SMS com fornecedores SMS configurados.

Depois de um deployment bem-sucedido, abra o FoxIDs Control Client em https://foxidscontrolxxxxxxxxxx.azurewebsites.net, o app service que comeca por foxidscontrol, o que o leva ao tenant master.

O utilizador admin predefinido e admin@foxids.com com password FirstAccess!, sendo obrigatorio alterar a password no primeiro login.

FoxIDs Control Client - Master tenant

Opcionalmente, navegue para o separador Users e crie mais utilizadores admin e atribua aos utilizadores o role admin com o valor foxids:tenant.admin.

FoxIDs Control Client - Master tenant admin user

Em geral, nao deve alterar a configuracao de application registrations e de metodos de autenticacao no tenant master, a menos que tenha a certeza do que esta a fazer. Em vez disso, continue para o passo seguinte para criar um tenant main.

Create main tenant

Crie um tenant main para os seus ambientes.

Considere os custom domains antes de criar o tenant main.

Clique em New Tenant e crie o tenant main.

FoxIDs Control Client - main tenant

Inicie sessao no tenant main, onde pode comecar a configurar as suas applications e os seus authentication methods.

Custom domains

Os custom domains sao configurados com custom primary domains e um custom domain no tenant main.

Custom primary domains

Os primary domains dos sites FoxIDs e FoxIDs Control podem ser personalizados. Os novos primary custom domains podem ser configurados nas App Services ou usando um reverse proxy.

Importante: altere o primary domain antes de adicionar tenants.

Domains:

O default domain do site FoxIDs e https://foxidsxxxx.azurewebsites.net, que pode ser alterado para um primary custom domain, por exemplo https://somedomain.com ou https://id.somedomain.com
O default domain do site FoxIDs Control e https://foxidscontrolxxxx.azurewebsites.net, que pode ser alterado para um primary custom domain, por exemplo https://control.somedomain.com

O site FoxIDs suporta um primary domain e varios custom domains ligados a tenants diferentes do tenant master. O site FoxIDs Control suporta apenas um primary domain.

Configure novos primary custom domains:

Inicie sessao no FoxIDs Control Client usando o primary domain predefinido, antigo. Selecione o separador Applications, depois clique em OpenID Connect - foxids_control_client e em Show advanced.
- Adicione o URL do novo primary custom domain do site FoxIDs Control a lista Allow CORS origins sem barra final.
- Adicione os redirect URIs de login e logout do novo primary custom domain do site FoxIDs Control Client a lista Redirect URIs, incluindo /master/authentication/login_callback e /master/authentication/logout_callback com barra final.
Se tiver adicionado tenants antes de alterar o primary domain, a configuracao OpenID Connect - foxids_control_client tem de ser efetuada em cada tenant.
Os custom primary domains sao configurados em cada App Service ou usando um reverse proxy. Dependendo do reverse proxy que estiver a usar, podera tambem ter de configurar os domains em cada App Service:
- Se configurado nas App Services: adicione os custom primary domains no portal Azure na FoxIDs App Service e na FoxIDs Control App Service, no separador Custom domains, clicando na ligacao Add custom domain.
- Se configurado no reverse proxy: os custom primary domains sao expostos atraves do reverse proxy.
Depois configure os novos primary custom domains do site de servico FoxIDs na FoxIDs App Service, no separador Environment variables:
- A definicao Settings__FoxIDsEndpoint e alterada para o novo primary custom domain do site FoxIDs.
E configure os novos primary custom domains do site de servico FoxIDs e do site FoxIDs Control na FoxIDs Control App Service, no separador Environment variables:
- A definicao Settings__FoxIDsEndpoint e alterada para o novo primary custom domain do site FoxIDs.
- A definicao Settings__FoxIDsControlEndpoint e alterada para o novo primary custom domain do site FoxIDs Control.

Custom domain on main tenant

Pode obter um URL mais curto e mais bonito em que o elemento tenant e removido do URL. Isto acontece ao configurar o primary custom domain do site FoxIDs no tenant main como custom domain.

Os custom domains sao suportados se o site FoxIDs estiver atras de um reverse proxy que possa fazer domain rewrite.
Ou, em alternativa, o FoxIDs suporta custom domains lendo o HTTP request domain e usando o domain como custom domain se a definicao Setting__RequestDomainAsCustomDomain estiver definida como true nas Environment variables da FoxIDs App Service. Neste caso, a FoxIDs App Service tem de ser configurada com o custom domain.

O domain e configurado no tenant main e marcado como verificado no tenant master.

Configure reverse proxy secret

Reverse proxy

Recomenda-se colocar tanto a FoxIDs Azure App service como a FoxIDs Control Azure App service atras de um reverse proxy.

Azure Front Door

O Azure Front Door pode ser configurado como reverse proxy. O Azure Front Door reescreve domains por predefinicao.

NAO ative caching. O header Accept-Language nao e encaminhado se o caching estiver ativado. O header e necessario para o FoxIDs suportar cultures.

Configuracao:

Adicione um endpoint Azure Front Door tanto para a FoxIDs App Service como para a FoxIDs Control App Service
Na secao Networking das App Services, ative a restricao de acesso para permitir trafego apenas do Azure Front Door
Adicione a definicao Settings__TrustProxyHeaders com o valor true nas Environment variables da FoxIDs App Service
Desative Session affinity
Opcionalmente configure politicas WAF

Alternative reverse proxy

Opcionalmente pode selecionar um reverse proxy alternativo.

Restrict access
Opcionalmente restrinja o acesso se estiver a usar um reverse proxy diferente do Azure Front Door.

Tanto o site FoxIDs como o site FoxIDs Control podem restringir o acesso com base no header HTTP X-FoxIDs-Secret.
A restricao de acesso e ativada ao adicionar um secret com o nome Settings--ProxySecret no Key Vault.

Conceda ao seu endereco IP acesso atraves da firewall do Key Vault
Conceda ao seu utilizador permissoes List e Set em Access policies.
Adicione o secret Settings--ProxySecret
Depois de uma configuracao bem-sucedida, remova o seu endereco IP e as permissoes.

As App Services precisam de ser reiniciadas para ler o secret.

Depois de o reverse proxy secret ser configurado no Key Vault, o reverse proxy precisa de adicionar o header HTTP X-FoxIDs-Secret em todas as chamadas backend para o FoxIDs para obter acesso.

Specify default page

Pode ser configurada uma default page alternativa para o site FoxIDs usando a definicao Settings__WebsiteUrl com, por exemplo, o valor https://www.foxidsxxxx.com nas Environment variables da FoxIDs App Service.

Troubleshooting deployment errors

Key Vault soft deleted

Se tiver eliminado um deployment anterior, o Key Vault fica apenas soft deleted e continua a existir com o mesmo nome durante alguns meses. Neste caso, pode deparar-se com um erro ConflictError com a mensagem Exist soft deleted vault with the same name..

A solucao e eliminar definitivamente, purge, o Key Vault antigo, o que libertara o nome.