Suporte a logon único
Introdução
A Redireção de Conteúdo do Navegador agora oferece uma experiência de usuário simplificada com suporte a logon único, permitindo autenticação no lado do VDA e compartilhamento de cookies.
Este aprimoramento elimina logins redundantes, aumentando a produtividade ao manter a autenticação e a persistência de cookies em todas as sessões de BCR, mesmo após o fechamento da janela do BCR.
Essa experiência contínua aprimora ainda mais a segurança, garantindo que a autenticação se origine do VDA, e não do cliente.
Sem logon único
- Abrir uma página autenticada dentro do BCR exigia que os usuários inserissem suas credenciais novamente a cada vez, quebrando a persistência do SSO.
- O SSO era mantido apenas enquanto a janela do BCR permanecia aberta; fechar e reabrir a janela forçava os usuários a repetir o processo de login.
- O fluxo de autenticação ocorria a partir do cliente, forçando os administradores a fornecer acesso à rede para sites de autenticação seguros a partir do dispositivo cliente.
Com logon único
- Os usuários não são mais solicitados a fornecer credenciais (quando já autenticados no VDA), pois o SSO é preservado de forma contínua a partir do navegador do VDA.
- A autenticação ocorre a partir do VDA, o que melhora a postura de segurança ao limitar os requisitos e a exposição da rede do lado do cliente, proporcionando uma experiência significativamente aprimorada e ininterrupta.
Requisitos mínimos
- Citrix Aplicativos Virtuais e Desktops 2511
- Citrix Aplicativo Workspace para Windows 2511
- Citrix Workspace App para Linux 2511 (Pré-visualização)
- Extensão de Redirecionamento do Navegador (Chrome ou Edge) 25.11 ou posterior
Sequências de autenticação suportadas
Existem dois tipos de sequências de autenticação atualmente suportadas com o Single sign-on do BCR.
Autenticação baseada em redirecionamento
Neste método padrão, o aplicativo usa um redirecionamento HTTP para forçar o usuário a uma página dedicada para autenticação.
Por exemplo, se um usuário tentar acessar https://my.intranet.app sem os cookies de sessão necessários, o aplicativo web responderá com um Redirecionamento HTTP 302 para o endpoint de autenticação, como https://my.intranet.app/auth .
Assim que o usuário se autentica com sucesso nessa página, o navegador é redirecionado de volta para a URL original do aplicativo, agora incluindo os cookies de autenticação necessários.
Autenticação baseada em formulários na página [Preview]
Este método mantém o usuário na URL do aplicativo pretendido enquanto apresenta dinamicamente a interface de login.
Por exemplo, se um usuário navegar para uma página protegida, como https://my.intranet.app , a página carrega o formulário de autenticação diretamente sem acionar um redirecionamento, porque os cookies necessários estão ausentes. Este processo pode envolver várias trocas internas entre a interface da página e o Identity Provider (IDP). Essas trocas continuam até que um cookie final e válido seja fornecido e utilizado, concedendo ao usuário acesso ao conteúdo da página original.
Nota:
Caso seu cenário não seja coberto pelos mecanismos especificados acima e não seja possível configurar seu aplicativo web para usar os mecanismos acima, entre em contato com a equipe de Produto da Citrix.
Configuração
Etapa 0: Introdução
Existem dois métodos para configurar o Single sign-on com BCR. A escolha do método de configuração depende do mecanismo de autenticação para os sites BCR desejados e da flexibilidade necessária para configurar vários aplicativos web para suporte a single sign-on.
Método 1: Este método usa as políticas BCR existentes no Web Studio e as utiliza para obter suporte a Single sign-on.
Antes da introdução do suporte a Single sign-on, a política de sites de autenticação de redirecionamento de conteúdo do navegador era usada para especificar as URLs usadas para autenticação (ou páginas intermediárias) a serem redirecionadas para o cliente, a fim de garantir que não houvesse interrupção no fluxo.
Com a introdução do suporte a Single sign-on, o BCR aproveitará os cookies de autenticação no navegador do lado do VDA e, portanto, as URLs na política de sites de autenticação agora precisam ser configuradas na política de lista de bloqueio de redirecionamento de conteúdo do navegador. Isso garante que a autenticação ocorra através do VDA.
Método 2: Este método opera com uma lógica semelhante ao Método 1, mas as URLs são configuradas via JSON (bcrconfig.json) e a URL JSON hospedada é chamada na política ACL do BCR. A configuração JSON oferece flexibilidade adicional.
- As empresas usam vários aplicativos web em seu ambiente, e cada aplicativo pode usar um mecanismo de autenticação diferente com base em sua implementação. O novo método JSON permite que a configuração seja mais intuitiva, robusta e escalável.
- Ao lidar com autenticação baseada em formulários na página, o Método 1 não oferece uma maneira de definir um cookie de autenticação específico, pois não há políticas existentes para suportar tal configuração. Portanto, se seu site requer autenticação baseada em formulários na página, JSON é a única maneira de fazê-lo.
Olhando para o futuro, o JSON oferece uma maneira escalável de introduzir recursos mais robustos, e a Citrix recomenda experimentar a configuração baseada em JSON.
Etapa 1: Determinando o mecanismo de autenticação
Para determinar qual Método usar para sua configuração, o primeiro passo é determinar que tipo de mecanismo de autenticação seu aplicativo está usando. Para determinar com precisão o método de autenticação do aplicativo web, a melhor abordagem é entrar em contato com o administrador do aplicativo web.
Se essa não for uma opção, você deve inspecionar as interações de solicitação/resposta nas ferramentas de desenvolvedor do navegador, na guia Rede, enquanto executa o fluxo de autenticação sem a extensão BCR instalada. Os seguintes resultados podem ajudá-lo a determinar o tipo de autenticação:
Para autenticação baseada em redirecionamento: Procure na coluna Status por uma ou mais respostas 302 (Redirecionamento). As respostas 302 devem conter um cabeçalho de localização apontando para a página de autenticação. Esta URL da página deve ser definida na política de lista de bloqueio de redirecionamento de conteúdo do navegador se você estiver usando o Método 1 e na seção denyList da configuração do aplicativo no arquivo bcrconfig.json se você estiver usando o Método 2.
Para autenticação baseada em formulários na página: Procure na coluna Método por várias solicitações POST. Uma das respostas posteriores a uma solicitação POST deve retornar um cabeçalho set-cookie com o cookie de autenticação específico do aplicativo web. Este cookie deve ser definido na seção de cookies da configuração do aplicativo no arquivo bcrconfig.json. Como o Método 1 não suporta autenticação baseada em formulários na página, o Método 2 é a única opção de configuração para este cenário.
Exemplo: Aqui está um exemplo com github.com. Este método pode ser usado para qualquer site que você deseja redirecionar com BCR e garantir que você tenha a configuração correta
- Abra o Chrome, então pressione CTRL+SHIFT+I para abrir suas ferramentas de desenvolvedor.
- Clique na guia Rede.
- Marque a configuração Preservar log.
- Clique no filtro Doc para simplificar os logs de rede.
- Clique com o botão direito ao lado de Nome e adicione a coluna URL.
- Navegue até github.com enquanto as ferramentas do desenvolvedor ainda estiverem abertas.
- Faça login em github.com
- Observe todos os saltos intermediários entre a página inicial do github.com e seu destino após o logon ter ocorrido.
- Analise os cabeçalhos de solicitação/resposta para determinar o tipo de autenticação conforme especificado acima.
Etapa 2: Escolha um método de configuração
-
Se você estiver lidando apenas com autenticação baseada em redirecionamento e não tiver necessidade de redirecionar vários aplicativos web com necessidades variadas (por exemplo, um aplicativo web com autenticação baseada em redirecionamento e outro aplicativo web com autenticação baseada em formulários na página), você pode escolher o Método 1 para configurar o Single sign-on.
-
Se você estiver lidando com autenticação baseada em formulários na página (ou) estiver lidando com vários aplicativos web com diferentes mecanismos de autenticação (ou) simplesmente quiser mais flexibilidade, mesmo que tenha apenas autenticação baseada em redirecionamento, você pode escolher o Método 2.
Etapa 3: Configurar
Método 1: Configurar o Single sign-on BCR com políticas existentes
- Habilite o recurso no VDA criando o seguinte valor de registro em
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream key: Dword BrowserProfileSharing value 1 - Configure a política de configuração ACL de redirecionamento de conteúdo do navegador com os sites a serem redirecionados. Nenhuma alteração na configuração neste aspecto.
- Caso você já tenha URLs configuradas na política de sites de autenticação, copie-as para a política de lista de bloqueio de redirecionamento de conteúdo do navegador e desative a política de sites de autenticação.
- Caso você não tenha configurado sites de autenticação / intermediários anteriormente, identifique as URLs intermediárias (a partir das interações de solicitação/resposta nas ferramentas de desenvolvedor do navegador, na guia Rede, ao realizar o fluxo de autenticação sem a extensão BCR instalada) e configure-as na lista de bloqueio.
Método 2: Configurar o Single sign-on do BCR com JSON
Criando bcrconfig.json
O bcrconfig.json pode conter várias configurações de aplicativos web. A extensão BCR tentará corresponder a URL solicitada a uma das allowList especificadas por um dos aplicativos no array de aplicativos e aplicará dinamicamente suas regras relacionadas para decidir como lidar com o redirecionamento de página e o processamento de single sign-on. As seguintes chaves podem ser utilizadas para controlar como um aplicativo web é tratado pela extensão BCR (observe que os valores booleanos devem estar em minúsculas, conforme as especificações JSON - apenas true ou false):
- appName [string value, mandatory]: Isso é usado principalmente internamente pela extensão e para fins de registro.
-
allowList [string array, mandatory]: Um aplicativo deve conter pelo menos uma URL em
allowList, que é a URL que se pretende redirecionar para que o cliente renderize a página, e não o VDA. Múltiplas URLs podem ser definidas, e curingas são aceitos. As regras de curinga são exatamente as mesmas da configuração de ACL de Redirecionamento de Conteúdo do Navegador. Por exemplo, para configurar todos os aplicativos Google para serem redirecionados, utilize o seguinte array:[“.google.com/”, “.google.com”, “.youtube.com”, “.youtube.com/”]
- denyList [string value, optional]: Defina as URLs para as quais o aplicativo web redireciona o usuário quando a autenticação é necessária. Esta configuração é principalmente essencial para autenticação baseada em redirecionamento, mas também pode ser usada para evitar redirecionamentos específicos em alguns fluxos de autenticação baseados em formulários. As URLs listadas nesta chave não serão redirecionadas para que a autenticação ocorra no lado do servidor. Você também pode usar isso quando o compartilhamento de perfil não é necessário para restringir sub-URLs específicas de um domínio para não serem redirecionadas para o cliente.
- profileSharing [boolean value, mandatory]: Este é o valor da chave que precisa ser definido para garantir que os cookies de autenticação de Single sign-on e outros cookies que armazenam as preferências do usuário sejam compartilhados, garantindo um comportamento consistente entre as páginas renderizadas no lado do servidor e no lado do cliente.
- cookies [string array, optional]: Defina um ou mais cookies de autenticação necessários para que o aplicativo web seja carregado sem solicitar ao usuário. A extensão então impedirá o redirecionamento do lado do cliente até que todos os cookies listados aqui sejam detectados como definidos para a URL do aplicativo web fornecido. Esta configuração é usada principalmente para autenticação baseada em formulários na página, mas também pode ser utilizada para autenticação baseada em redirecionamento, além de especificar denyList em certos cenários.
-
deleteClientCache[boolean value, optional]: Se o mecanismo de configuração
bcrconfig.jsonfor usado, o cliente BCR exclui seu cache do navegador por padrão para maior segurança. Esse processo ocorre quando o usuário fecha todas as guias redirecionadas ou inicia uma página redirecionada pela primeira vez em uma sessão. Defina o valor desta chave como false para evitar esse comportamento. Se o dispositivo cliente for confiável, definir esta chave como false pode melhorar a experiência do usuário. Se o dispositivo cliente não for confiável, não definir esta chave (ou) defini-la como true pode melhorar a postura de segurança. - schemaVersion [string value, mandatory]: Isso é usado principalmente internamente pela extensão e para fins de registro. No momento desta redação, seu valor deve ser definido como 2511.
Exemplo de Configuração
{
"apps": [
{
"appName": "myWebApp1",
"allowList": [
"https://myWebApp1.com/*"
],
"denyList": [],
"requires": {
"profileSharing": false,
"cookies": []
}
},
{
"appName": "myWebApp2",
"allowList": [
"https://myWebApp2.com/*"
],
"denyList": [
"https://myWebApp2.com/authPortal/*"
],
"requires": {
"profileSharing": true,
"cookies": []
}
},
{
"appName": "myWebApp3",
"allowList": [
"https://*.myWebApp3.com/"
],
"denyList": [
"https://myWebApp3.com/authPortal/*"
],
"requires": {
"profileSharing": true,
"cookies": [
"requiredAuthCookie1",
"requiredAuthCookie2"
]
}
}
],
"preferences": {
"deleteClientCache": true
},
"schemaVersion": "2511"
}
<!--NeedCopy-->
Aqui está um arquivo bcrconfig.json de exemplo. Seus elementos são explicados em detalhes abaixo:
A estrutura JSON acima contém 3 aplicativos com configurações diferentes:
Cenário myWebApp1, sem SSO:
- O valor do array de strings da chave
allowListespecifica que todos os caminhos dentro de https://myWebApp1.com devem ser redirecionados para o cliente, exceto os valores listados na chavedenyList, se houver. - O valor do array de strings da chave
denyListestá vazio, então nenhum site de autenticação será impedido de redirecionamento. Assim, a autenticação não será mantida estritamente no lado do servidor. - O valor booleano da chave
profileSharingestá definido como false, então nenhum cookie pertencente às entradasallowListserá compartilhado com o cliente. - O array de strings da chave de cookies está vazio, mas teria sido ignorado de qualquer forma, já que a chave de compartilhamento
profileSharingestá definida como false.
myWebApp2, cenário de autenticação baseada em redirecionamento:
-
O valor do array de strings da chave
allowListespecifica que todos os caminhos dentro de https://myWebApp2.com devem ser redirecionados para o cliente, exceto os valores listados na chavedenyList, se houver. -
O valor do array de strings da chave
denyListespecifica que os caminhos que começam com/authPortal/no domínio myWebApp2.com serão impedidos de redirecionamento do lado do cliente para que a autenticação do lado do servidor possa ser realizada. -
O valor booleano da chave
profileSharingestá definido como true, então os cookies pertencentes às entradas da allowList serão compartilhados com o cliente e o logon único será efetuado. -
O array de strings da chave de cookies está vazio, então a extensão não esperará que um cookie específico seja definido após a autenticação do lado do servidor antes que eles sejam compartilhados com o cliente.
myWebApp3, cenário de autenticação baseada em formulários:
- O valor do array de strings da chave
allowListespecifica que todos os caminhos dentro de https://myWebApp3.com devem ser redirecionados para o cliente, exceto os valores listados na chavedenyList, se houver. - O valor do array de strings da chave
denyListespecifica que os caminhos que começam com/authPortal/no domínio myWebApp2.com serão impedidos de redirecionamento do lado do cliente para que a autenticação do lado do servidor possa ser realizada. - O valor booleano da chave
profileSharingestá definido como true, então os cookies pertencentes às entradasallowListserão compartilhados com o cliente. - O array de strings da chave de cookies contém um nome de cookie, portanto, a extensão aguardará que este cookie seja definido após a autenticação do lado do servidor. O cookie para o URL relacionado em
allowListserá compartilhado com o cliente e ocorrerá o redirecionamento do lado do cliente.
Preferências
- A chave
deleteClientCacheestá definida como true, portanto, o cliente BCR exclui seu cache do navegador por padrão para maior segurança. Este é o comportamento padrão, mesmo que a chave não esteja definida.
Configurando a política BCR
Depois de criar o bcrconfig.json, siga as etapas abaixo para configurar a configuração ACL de redirecionamento de conteúdo do navegador para usar o conteúdo do arquivo JSON.
-
Nomeie o arquivo com a extensão
.bcrconfig.json, por exemplo,myrules.bcrconfig.json -
Hospede o arquivo JSON em um servidor web acessível ao VDA e anote o URL.
Nota:
O servidor deve permitir downloads de arquivos; os sites do Microsoft IIS permitem downloads de arquivos JSON por padrão.
-
No Citrix Studio, em Políticas, adicione o URL da etapa anterior à configuração ACL de redirecionamento de conteúdo do navegador:
Nota:
Outras entradas na configuração ACL de redirecionamento de conteúdo do navegador podem permanecer. A Extensão BCR prioriza as configurações
bcrconfig.jsonse surgirem conflitos. A Citrix recomenda transferir toda a configuração para JSON para facilitar o gerenciamento, a configuração em nível de aplicativo e a escalabilidade. -
Salve a política e inicie uma sessão para testar a configuração da política.
Nota:
Após definir a política, você pode editar o arquivo
bcrconfig.jsonhospedado a qualquer momento para ajuste. O arquivo recarrega e aplica as alterações somente quando o processo principal do navegador que executa a extensão BCR é iniciado ou reiniciado.
Nota:
Em essência, da perspectiva da política, você só precisa habilitar a política de Redirecionamento de Conteúdo do Navegador (que é habilitada por padrão) e configurar a política de configuração de ACL de Redirecionamento de Conteúdo do Navegador com a URL que aponta para o arquivo JSON.
A configuração JSON atualmente se aplica às seguintes políticas e as torna flexíveis, mas o restante das políticas continua a realizar as mesmas ações de antes.
- Configuração de ACL de redirecionamento de conteúdo do navegador: As URLs na ACL agora podem ser configuradas via JSON através da chave
allowList.- Configuração da lista de bloqueio de redirecionamento de conteúdo do navegador: A lista de bloqueio agora pode ser configurada via JSON através da chave
denyList.- Sites de autenticação de redirecionamento de conteúdo do navegador: Os sites de autenticação também podem ser configurados via JSON através da chave
denyList.