Configurar o NGINX Plus para SAML SSO com o Microsoft Entra ID

Para aumentar a segurança e melhorar a experiência do usuário, o F5 NGINX Plus (R29+) agora tem suporte para Security Assertion Markup Language (SAML). Um protocolo bem estabelecido que fornece logon único (SSO) para aplicativos da web, o SAML permite que um provedor de identidade (IdP) autentique usuários para acesso a um recurso e, em seguida, passe essas informações para um provedor de serviços (SP) para autorização.

Nesta postagem do blog, abordamos passo a passo como integrar o NGINX com o Microsoft Entra ID , anteriormente conhecido como Azure Active Directory (Azure AD), usando um aplicativo Web que não oferece suporte nativo ao SAML. Também abordamos como implementar o SSO para o aplicativo e integrá-lo ao ecossistema Microsoft Entra ID. Ao seguir o tutorial, você também aprenderá como o NGINX pode extrair declarações de uma asserção SAML (incluindo UPN, nome, sobrenome e associações de grupo) e, em seguida, passá-las para o aplicativo por meio de cabeçalhos HTTP.

O tutorial inclui três etapas:

1. Configurando o Microsoft Entra ID como um IdP
2. Configurando as configurações SAML e NGINX Plus como um proxy reverso
3. Testando a configuração

Para concluir este tutorial, você precisa:

• NGINX Plus (R$ 29+), que você pode obter como um teste gratuito de 30 dias
• Uma conta Microsoft Entra ID gratuita ou empresarial
• Um certificado SSL/TLS válido instalado no servidor NGINX Plus (este tutorial usa dev.sports.com.crt e dev.sports.com.key )
• Para verificar as asserções SAML, o que pode ser feito baixando o certificado público demonginx.cer do IdP

Observação : Este tutorial não se aplica a implantações do NGINX Open Source porque o armazenamento de chave-valor é exclusivo do NGINX Plus.

Usando o NGINX Plus como um provedor de serviços SAML

Nessa configuração, o NGINX Plus atua como um SP SAML e pode participar de uma implementação de SSO com um IdP SAML, que se comunica indiretamente com o NGINX Plus por meio do Agente do Usuário.

O diagrama abaixo ilustra o fluxo do processo SSO, com iniciação de SP e vinculações POST para solicitação e resposta. É importante observar novamente que esse canal de comunicação não é direto e é gerenciado pelo Agente do Usuário.

Figura 1: SSO iniciado por SAML SP com vinculações POST para AuthnRequest e Response

Passo 1: Configurar o Microsoft Entra ID como um provedor de identidade

Para acessar o portal de gerenciamento do Microsoft Entra ID, entre e navegue até o painel esquerdo. Selecione Microsoft Entra ID e clique no título do diretório que requer configuração de SSO. Depois de selecionado, escolha Aplicativos corporativos .

Figura 2: Escolha de aplicativos corporativos no portal de gerenciamento

Para criar um aplicativo, clique no botão Novo aplicativo na parte superior do portal. Neste exemplo, criamos um aplicativo chamado demonginx .

Figura 3: Criando um novo aplicativo no Microsoft Entra ID

Depois de ser redirecionado para a Visão geral do aplicativo recém-criado, vá para Introdução no menu à esquerda e clique em Logon único em Gerenciar . Em seguida, selecione SAML como o método de logon único .

Figura 4: Usando a seção SSO para iniciar a configuração SAML

Para configurar o SSO em seu aplicativo empresarial, você precisa registrar o NGINX Plus como um SP dentro do Microsoft Entra ID. Para fazer isso, clique no ícone de lápis ao lado de Edit em Basic SAML Configuration , como visto na Figura 5.

Adicione os seguintes valores e clique em Salvar :

• Identificador (ID da entidade) – https://dev.sports.com
• URL de resposta (URL do serviço de consumidor de declaração) – https://dev.sports.com/saml/acs
• URL de login : https://dev.sports.com
• URL de logout (opcional) : https://dev.sports.com/saml/sls

O uso de certificados de verificação é opcional. Ao habilitar esta configuração, duas opções de configuração no NGINX devem ser abordadas:

1. Para verificar a assinatura com uma chave pública, você precisa definir $saml_sp_sign_authn como true . Isso instrui o SP a assinar o AuthnRequest enviado ao IdP.
2. Forneça o caminho para a chave privada que será usada para esta assinatura configurando $saml_sp_signing_key . Certifique-se de carregar o certificado de chave pública correspondente no Microsoft Entra ID para verificação de assinatura.

Observação : Nesta demonstração, atributos e declarações foram modificados, e novos atributos SAML foram adicionados. Esses atributos SAML são enviados pelo IdP. Certifique-se de que sua configuração do NGINX esteja definida para receber e processar corretamente esses atributos. Você pode verificar e ajustar as configurações relacionadas no repositório NGINX GitHub .

Baixe o Certificado IdP (Raw) do Microsoft Entra ID e salve-o na sua instância do NGINX Plus.

Figura 5: Baixando o Certificado IdP (Raw) do Microsoft Entra ID

Figura 6: Adicionar um novo usuário ou grupo

No Microsoft Entra ID, você pode conceder acesso aos aplicativos da sua empresa habilitados para SSO adicionando ou atribuindo usuários e grupos.

No menu à esquerda, clique em Usuário e grupos e depois no botão superior Adicionar usuário/grupo .

Passo 2: Configurar as configurações SAML e NGINX Plus como um proxy reverso

Certifique-se de ter os certificados necessários antes de configurar arquivos no seu NGINX Plus SP:

• Certificados para encerrar sessão TLS ( dev.sports.com.crt e dev.sports.com.key )
• Certificado baixado do Microsoft Entra ID para verificação de assinatura do IdP ( demonginx.cer )

Observação : Os certificados precisam estar no formato SPKI.

Para iniciar esta etapa, baixe o certificado IdP do Microsoft Entra ID para verificação de assinatura. Em seguida, converta o formato PEM para DER:

Caso você queira verificar asserções SAML SP, é recomendável usar chaves públicas/privadas diferentes daquelas usadas para terminação TLS.

Extraia o certificado de chave pública no formato SPKI:

Edite o arquivo frontend.conf para atualizar estes itens:

• ssl_certificate – Atualizar para incluir o caminho do certificado TLS.
• ssl_certificate_key – Atualização para incluir o caminho da chave privada TLS.

Na implantação de produção, você pode usar diferentes destinos de backend com base nos requisitos do negócio. Neste exemplo, o backend fornece uma resposta personalizada:

Modificamos os atributos e declarações no Microsoft Entra ID adicionando novas declarações para o e-mail e objectid do usuário. Essas atualizações permitem que você forneça uma resposta mais personalizada e adaptada ao seu aplicativo, resultando em uma melhor experiência do usuário.

Figura 7: Atributos e declarações modificados no Microsoft Entra ID

O próximo passo é configurar o NGINX, que fará o proxy do tráfego para o aplicativo de backend. Nesta demonstração, o aplicativo SAML de backend está disponível publicamente em https://dev.sports.com .

Edite seu arquivo frontend.conf :

# Este é o arquivo frontend.conf 
# Este é o aplicativo de backend que estamos protegendo com SAML SSO 
upstream my_backend { 
zone my_backend 64k; 
server dev.sports.com; 
} 

# Formato de log personalizado para incluir o assunto 'NameID' no campo REMOTE_USER 
log_format saml_sso '$remote_addr - $saml_name_id [$time_local] "$request" "$host" ' 
'$status $body_bytes_sent "$http_referer" ' 
'"$http_user_agent" "$http_x_forwarded_for"'; 

# O servidor frontend - proxy reverso com autenticação SAML SSO 
# 
server { 
# Locais funcionais implementando suporte SAML SSO 
include conf.d/saml_sp.server_conf; 

# Reduza o nível de gravidade conforme necessário 
error_log /var/log/nginx/error.log debug; 
listen 443 ssl; 
ssl_certificate /home/ubuntu/dev.sports.com.crt; 
ssl_certificate_key /home/ubuntu/dev.sports.com.key; 
ssl_session_cache shared:SSL:5m; 

location / { 
# Quando um usuário não é autenticado (por exemplo, a variável "saml_access_granted." 
# não está definida como "1"), um erro HTTP 401 Unauthorized é 
# retornado, que é manipulado pelo @do_samlsp_flow nomeado location. 
error_page 401 = @do_samlsp_flow; 

if ($saml_access_granted != "1") { 
return 401; 
} 

# Usuários autenticados com sucesso são enviados por proxy para o backend, 
# com o atributo NameID passado como um cabeçalho HTTP 
proxy_set_header mail $saml_attrib_mail; # Microsoft Entra ID's user.mail 
proxy_set_header objectid $saml_attrib_objectid; # Microsoft Entra ID's objectid 
access_log /var/log/nginx/access.log saml_sso; 
proxy_pass http://my_backend; 
proxy_set_header Host dev.sports.com; 
return 200 "Bem-vindo à página do aplicativo\n Meu objectid é $http_objectid\n Meu e-mail é $http_mail\n"; 
default_type text/plain; 

} 
} 
# vim: syntax=nginx         

Para que os atributos saml_attrib_mail e saml_attrib_ objectid sejam refletidos nas configurações do NGINX, atualize a parte de armazenamento de chave-valor do saml_sp_configuration.conf da seguinte maneira:

keyval_zone zona=saml_attrib_mail:1M estado=/var/lib/nginx/state/saml_attrib_email.json tempo limite=1h; 
keyval $cookie_auth_token $saml_attrib_mail zona=saml_attrib_mail; 

keyval_zone zona=saml_attrib_objectid:1M estado=/var/lib/nginx/state/saml_attrib_objectid.json tempo limite=1h; 
keyval $cookie_auth_token $saml_attrib_objectid zona=saml_attrib_objectid; 

Em seguida, configure o arquivo de configuração do SAML SSO. Este arquivo contém as configurações primárias para o SP e o IdP. Para personalizá-lo de acordo com sua configuração específica de SP e IdP, você precisa ajustar os vários blocos map{} incluídos no arquivo.

Esta tabela fornece descrições das variáveis dentro de saml_sp_configuration.conf :

O código abaixo mostra os valores editados somente para este caso de uso em saml_sp_configuration.conf.

Observação : Certifique-se de que as partes restantes do arquivo de configuração ainda apareçam no arquivo (por exemplo, os armazenamentos de chave-valor). Certifique-se também de ajustar corretamente as variáveis no arquivo saml_sp_configuration.conf com base na sua implantação.

 # Configuração do SAML SSO 

map $host $saml_sp_entity_id { 
# Identificador exclusivo que identifica o SP para o IdP. 
# Deve ser URL ou URN. 
default "https://dev.sports.com"; 
} 

map $host $saml_sp_acs_url { 
# A URL do ACS, um ponto de extremidade no SP para onde o IdP 
# será redirecionado com sua resposta de autenticação. 
# Deve corresponder ao local do ACS definido no arquivo "saml_sp.serer_conf". 
default "https://dev.sports.com/saml/acs"; 
} 

map $host $saml_sp_request_binding { 
# Refere-se ao método pelo qual uma solicitação de autenticação é enviada do 
# SP para um IdP durante o processo de Single Sign-On (SSO).
# Somente métodos HTTP-POST ou HTTP-Redirect são permitidos. 
default 'HTTP-POST'; 
} 

map $host $saml_sp_sign_authn { 
# Se o SP deve assinar o AuthnRequest enviado ao IdP. 
default "false"; 
} 

map $host $saml_sp_decryption_key { 
# Especifica a chave privada que o SP usa para descriptografar a asserção criptografada 
# ou NameID do IdP. 
default ""; 
} 

map $host $saml_sp_force_authn { 
# Se o SP deve forçar a reautenticação do usuário pelo IdP. 
default "false"; 
} 

map $host $saml_sp_nameid_format { 
# Indica o formato desejado do identificador de nome na asserção SAML 
# gerada pelo IdP. Verifique a seção 8.3 da especificação SAML 2.0 Core 
# (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) 
# para a lista de formatos NameID permitidos. 
default "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"; 
} 

map $host $saml_sp_relay_state { 
# URL relativa ou absoluta para a qual o SP deve redirecionar 
# após o logon bem-sucedido. 
default ""; 
} 

map $host $saml_sp_want_signed_response { 
# Se o SP deseja que a resposta SAML do IdP 
# seja assinada digitalmente. 
default "false"; } 

map $host $saml_sp_want_signed_assertion { 
# Se o SP deseja que a Asserção SAML do IdP 
# seja assinada digitalmente. 
default "true"; 
} 

map $host $saml_sp_want_encrypted_assertion { 
# Se o SP deseja que a Asserção SAML do IdP 
# seja criptografada. 
default "false"; 
} 

map $host $saml_idp_entity_id { 
# Identificador exclusivo que identifica o IdP para o SP. 
# Deve ser URL ou URN. 
default "https://sts.windows.net/8807dced-9637-4205-a520-423077750c60/"; } 

map $host $saml_idp_sso_url { 
# Ponto de extremidade do IdP para o qual o SP enviará o SAML AuthnRequest para iniciar 
# um processo de autenticação. 
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_idp_verification_certificate { 
# Arquivo de certificado que será usado para verificar a assinatura digital 
# na Resposta SAML, LogoutRequest ou LogoutResponse recebida do IdP. 
# Deve ser uma chave pública no formato PKCS#1. Veja a documentação sobre como converter 
# X.509 PEM para o formato DER. 
default "/etc/nginx/conf.d/demonginx.spki"; 
} 

######### Logout Único (SLO) ######### 

map $host $saml_sp_slo_url { 
# Ponto de extremidade do SP para o qual o IdP enviará o SAML LogoutRequest para iniciar 
# um processo de logout ou LogoutResponse para confirmar o logout. 
default "https://dev.sports.com/saml/sls"; 
} 

map $host $saml_sp_slo_binding { 
# Refere-se ao método pelo qual um LogoutRequest ou LogoutResponse 
# é enviado do SP para um IdP durante o processo de Logout Único (SLO).
# Somente métodos HTTP-POST ou HTTP-Redirect são permitidos. 
default 'HTTP-POST'; 
} 

map $host $saml_sp_sign_slo { 
# Se o SP deve assinar o LogoutRequest ou LogoutResponse 
# enviado ao IdP. 
default "false"; 
} 

map $host $saml_idp_slo_url { 
# Ponto de extremidade do IdP para o qual o SP enviará o LogoutRequest para iniciar 
# um processo de logout ou LogoutResponse para confirmar o logout. 
# Se não for definido, o recurso SAML Single Logout (SLO) será DESATIVADO e 
# as solicitações para o local 'logout' resultarão no encerramento 
# da sessão do usuário e em um redirecionamento para a página de destino do logout.
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_sp_want_signed_slo { 
# Se o SP deseja que o SAML LogoutRequest ou LogoutResponse do IdP 
# seja assinado digitalmente. 
default "true"; 
} 

map $host $saml_logout_landing_page { 
# Para onde redirecionar o usuário após solicitar o local /logout. Isto pode ser 
# substituído por uma página de logout personalizada ou URL completa. 
default "/_logout"; # Página de logout simples e integrada 
} 

map $proto $saml_cookie_flags { 
http "Path=/; SameSite=lax;"; # Para testes HTTP/texto simples 
https "Path=/; SameSite=lax; HttpOnly; Secure;"; # Recomendação de produção 
} 

map $http_x_forwarded_port $redirect_base { 
"" $proto://$host:$server_port; 
default $proto://$host:$http_x_forwarded_port; 
} 

map $http_x_forwarded_proto $proto { 
"" $scheme; 
default $http_x_forwarded_proto; 
} 
# CONFIGURAÇÃO AVANÇADA ABAIXO DESTA LINHA 
# Configuração avançada adicional (contexto do servidor) em saml_sp.server_conf 

######### Zonas de memória compartilhada que mantêm os bancos de dados de chave-valor relacionados ao SAML 

# Zona para armazenar identificadores de mensagem AuthnRequest e LogoutRequest (ID) 
# para evitar ataques de repetição. (OBRIGATÓRIO) 
# O tempo limite determina quanto tempo o SP espera por uma resposta do IDP, 
# ou seja, quanto tempo o processo de autenticação do usuário pode levar. 
keyval_zone zone=saml_request_id:1M state=/var/lib/nginx/state/saml_request_id.json timeout=5m; 

# Zona para armazenar identificadores de mensagem de resposta SAML (ID) para evitar ataques de repetição. (OBRIGATÓRIO) 
# O tempo limite determina por quanto tempo o SP mantém os IDs para evitar a reutilização. 
keyval_zone zone=saml_response_id:1M state=/var/lib/nginx/state/saml_response_id.json timeout=1h; 

# Zona para armazenar informações de acesso à sessão SAML. (OBRIGATÓRIO) 
# O tempo limite determina por quanto tempo o SP mantém a decisão de acesso à sessão (o tempo de vida da sessão). 
keyval_zone zone=saml_session_access:1M state=/var/lib/nginx/state/saml_session_access.json timeout=1h; 

# Zona para armazenar valores SAML NameID. (OBRIGATÓRIO)
# O tempo limite determina por quanto tempo o SP mantém os valores NameID. Deve ser igual ao tempo de vida da sessão. 
keyval_zone zone=saml_name_id:1M state=/var/lib/nginx/state/saml_name_id.json timeout=1h; 

# Zona para armazenar valores de formato SAML NameID. (OBRIGATÓRIO)
# O tempo limite determina por quanto tempo o SP mantém os valores do formato NameID. Deve ser igual ao tempo de vida da sessão. 
keyval_zone zone=saml_name_id_format:1M state=/var/lib/nginx/state/saml_name_id_format.json timeout=1h; 

# Zona para armazenar valores SAML SessionIndex. (OBRIGATÓRIO)
# O tempo limite determina por quanto tempo o SP mantém os valores do SessionIndex. Deve ser igual ao tempo de vida da sessão. 
keyval_zone zone=saml_session_index:1M state=/var/lib/nginx/state/saml_session_index.json timeout=1h; 

# Zona para armazenar valores SAML AuthnContextClassRef. (OBRIGATÓRIO)
# O tempo limite determina por quanto tempo o SP mantém os valores AuthnContextClassRef. Deve ser igual ao tempo de vida da sessão. 
keyval_zone zone=saml_authn_context_class_ref:1M state=/var/lib/nginx/state/saml_authn_context_class_ref.json timeout=1h; 

# Zonas para armazenar valores de atributos SAML. (OPCIONAL) 
# O tempo limite determina por quanto tempo o SP mantém os valores dos atributos. Deve ser igual ao tempo de vida da sessão. 
keyval_zone zone=saml_attrib_uid:1M state=/var/lib/nginx/state/saml_attrib_uid.json timeout=1h; 
keyval_zone zone=saml_attrib_name:1M state=/var/lib/nginx/state/saml_attrib_name.json timeout=1h; 
keyval_zone zone=saml_attrib_memberOf:1M state=/var/lib/nginx/state/saml_attrib_memberOf.json timeout=1h; 

######### Variáveis relacionadas a SAML cujo valor é pesquisado pela chave (cookie de sessão) no banco de dados de chave-valor. 

# Obrigatório: 
keyval $saml_request_id $saml_request_redeemed zone=saml_request_id; # ID da solicitação SAML 
keyval $saml_response_id $saml_response_redeemed zone=saml_response_id; # ID da resposta SAML 
keyval $cookie_auth_token $saml_access_granted zone=saml_session_access; # Decisão de acesso SAML 
keyval $cookie_auth_token $saml_name_id zone=saml_name_id; # ID do nome SAML 
keyval $cookie_auth_token $saml_name_id_format zone=saml_name_id_format; # SAML NameIDFormat 
keyval $cookie_auth_token $saml_session_index zone=saml_session_index; # Índice de sessão SAML 
keyval $cookie_auth_token $saml_authn_context_class_ref zone=saml_authn_context_class_ref; # SAML AuthnContextClassRef 

# Opcional: 
keyval $cookie_auth_token $saml_attrib_uid zone=saml_attrib_uid; 
keyval $cookie_auth_token $saml_attrib_name zone=saml_attrib_name; 
keyval $cookie_auth_token $saml_attrib_memberOf zone=saml_attrib_memberOf; 

keyval_zone zone=saml_attrib_mail:1M state=/var/lib/nginx/state/saml_attrib_mail.json timeout=1h; 
keyval $cookie_auth_token $saml_attrib_mail zone=saml_attrib_mail; 

keyval $cookie_auth_token $saml_attrib_objectid zone=saml_attrib_objectid; 
keyval_zone zone=saml_attrib_objectid:1M state=/var/lib/nginx/state/saml_attrib_objectid.json timeout=1h; 

######### Importa um módulo que implementa a funcionalidade SAML SSO e SLO 
js_import samlsp from conf.d/saml_sp.js; 

Etapa 3: Testando a configuração

Duas partes são necessárias para testar a configuração:

1. Verificando o fluxo SAML
2. Testando a funcionalidade de logout iniciada pelo SP

Verificando o fluxo SAML

Depois de configurar o SAML SP usando o NGINX Plus e o IdP usando o Microsoft Entra ID, é crucial validar o fluxo SAML. Esse processo de validação garante que a autenticação do usuário por meio do IdP seja bem-sucedida e que o acesso aos recursos protegidos pelo SP seja concedido.

Para verificar o fluxo SAML iniciado pelo SP, abra seu navegador preferido e digite https://dev.sports.com na barra de endereço. Isso o direcionará para a página de login do IdP.

Figura 8: A página de login do IdP

Insira as credenciais de um usuário que está configurado na página de login do IdP. O IdP autenticará o usuário após o envio.

Figura 9: Inserindo as credenciais do usuário configurado

O usuário receberá acesso ao recurso protegido solicitado anteriormente após estabelecer uma sessão com sucesso. Posteriormente, esse recurso será exibido no navegador do usuário.

Figura 10: A página do aplicativo foi carregada com sucesso

Informações valiosas sobre o fluxo SAML podem ser obtidas verificando os logs do SP e do IdP. No lado do SP (NGINX Plus), certifique-se de que os cookies auth_token estejam definidos corretamente. No lado do IdP (ID do Microsoft Entra), certifique-se de que o processo de autenticação seja concluído sem erros e que a asserção SAML seja enviada ao SP.

O NGINX access.log deve ficar assim:

127.0.0.1 - - [14/Aug/2023:21:25:49 +0000] "GET / HTTP/1.0" 200 127 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, como Gecko) Versão/16.1 Safari/605.1.15" "-" 99.187.244.63 - Akash Ananthanarayanan [14/ago/2023:21:25:49 +0000] "OBTER / HTTP/1.1" "dev.sports.com" 200 127 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, como Gecko) Versão/16.1 Safari/605.1.15" "- 

Enquanto o NGINX debug.log se parece com isto:

2023/08/14 21:25:49 [informações] 27513#27513: *399 js: Sucesso do SAML SP, criando sessão _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d 

Testando a funcionalidade de logout iniciada pelo SP

O SAML Single Logout (SLO) permite que os usuários efetuem logout de todos os IdPs e SPs envolvidos com uma única ação. O NGINX Plus oferece suporte a cenários de logout iniciados por SP e IdP, melhorando a segurança e a experiência do usuário em ambientes SSO. Neste exemplo, usamos um cenário de logout iniciado pelo SP.

Figura 11: SLO iniciado por SAML SP com ligações POST/redirecionamento para LogoutRequest e LogoutResponse

Após autenticar sua sessão, efetue logout acessando a URL de logout configurada no seu SP. Por exemplo, se você configurou https://dev.sports.com/logout como URL de logout no NGINX Plus, insira essa URL na barra de endereços do seu navegador.

Figura 12: Saindo da sessão com sucesso

Para garantir um logout seguro, o SP deve iniciar uma solicitação SAML que é então verificada e processada pelo IdP. Esta ação efetivamente encerra a sessão do usuário, e o IdP enviará uma resposta SAML para redirecionar o navegador do usuário de volta ao SP.

Conclusão

Parabéns! O NGINX Plus agora pode servir como um SAML SP, fornecendo outra camada de segurança e conveniência ao processo de autenticação. Esse novo recurso é um avanço significativo para o NGINX Plus, tornando-o uma solução mais robusta e versátil para organizações que priorizam segurança e eficiência. 

Saiba mais sobre o uso do SAML com o NGINX Plus

Você pode começar a usar o SAML com o NGINX Plus hoje mesmo iniciando uma avaliação gratuita de 30 dias do NGINX Plus . Esperamos que você ache isso útil e agradecemos seu feedback.

Mais informações sobre o NGINX Plus com SAML estão disponíveis nos recursos abaixo.

• Anunciando o NGINX Plus R29
• Suporte SAML no NGINX Plus como uma implementação de referência no GitHub