Acesso ao portal APM: de quem é a sessão da aplicação?

Publicar uma aplicação de intranet através do BIG-IP APM Portal Access é uma decisão sobre sessões, não sobre copiar um servidor virtual. O portal admite o utilizador, o perfil de reescrita mantém os pedidos selecionados no caminho do gateway e a aplicação continua a ter uma sessão própria. Cinco verificações separam um desenho que se comporta de forma previsível de outro em que o serviço de assistência descobre os tempos limite utilizador a utilizador. Percorra-as por ordem e pare na primeira que não se verifique.

Verificação 1: o recurso está publicado, não apenas ligado

Um marcador no webtop prova que um utilizador vê uma entrada. Não prova que a aplicação está publicada. Procure o perfil de acesso, o perfil de reescrita e o servidor virtual que os combina, e confirme depois que a atribuição do recurso aponta para a aplicação que pensa. Se faltar ou for incoerente qualquer dos três, o resto da lista não faz sentido.

O caso de publicação a meio parece saudável no ponto de entrada. O servidor virtual transporta o perfil de acesso enquanto o perfil de reescrita está limitado a outro URI de recurso, pelo que a entrada do webtop aparece e a primeira página carrega, e depois os pedidos do subcaminho abandonam o caminho do gateway e chegam ao backend diretamente. A imagem inversa é um recurso atribuído à aplicação errada: o marcador abre, e abre algo que ninguém aprovou.

Verificação 2: a sessão do backend é um estado à parte

O backend pode exigir a sua própria autenticação mesmo quando o APM considera o utilizador com sessão iniciada. A integração SSO suportada estabelece essa relação por si, mas aceitar o início de sessão do portal não faz com que cada aplicação aceite as mesmas credenciais ou o mesmo cookie de sessão. Se o SSO não estiver configurado para o recurso, a aplicação pedirá o seu próprio início de sessão dentro de um portal já autenticado.

Desativar o SSO para mudar o aviso visível é um atalho comum e mau: altera o desenho da autenticação sem tocar no ciclo de vida que produziu o aviso. Decida em vez disso se o início de sessão do backend deve aparecer de todo, e se deve, torne-o parte explícita do fluxo publicado.

Verificação 3: há dois relógios, e não são o mesmo relógio

O perfil de acesso do APM transporta um tempo limite de inatividade e uma vida máxima da sessão. A aplicação transporta o seu próprio temporizador de inatividade e a expiração do cookie. Aumentar o temporizador do portal não prolonga a sessão da aplicação, e encurtar a sessão da aplicação não termina a sessão do portal.

A chamada clássica ao serviço de assistência nasce de um par desalinhado: o portal ainda é válido, a sessão da aplicação não, e o utilizador vê um formulário de início de sessão que parece contradizer o portal. É um comportamento correto, não uma avaria, e a solução é escolher qual relógio deve expirar primeiro para esta aplicação.

Verificação 4: o encerramento de sessão tem um âmbito definido

Escreva o que o botão de saída da aplicação deve terminar: apenas essa aplicação, toda a sessão APM ou uma sessão mais ampla do fornecedor de identidade. O perfil de acesso suporta uma lista de URI de saída com um atraso opcional, e é assim que faz o encerramento de sessão da aplicação terminar a sessão do portal quando é esse o requisito. Sem isso, a saída da aplicação deixa o portal vivo, e um pedido seguinte pode voltar a iniciar sessão ao utilizador em silêncio.

Considere o efeito sobre outros recursos do mesmo portal. Se terminar a sessão de uma aplicação terminar a sessão de outras seis, os utilizadores chamarão a isso um erro, a menos que o comportamento tenha sido acordado antes com o proprietário da aplicação. Fechar um separador e voltar ao webtop não são prova de que algo terminou.

Verificação 5: a aplicação sobrevive à reescrita

O Portal Access reescreve conteúdo web selecionado, e a reescrita tem limites. As funcionalidades modernas do lado do cliente, os processos em segundo plano, os fluxos de carregamento e o início de sessão federado podem ficar fora do que uma dada versão trata. A matriz de compatibilidade por versão da F5 é o documento a ler antes de se comprometer, porque os limites dependem da versão.

Teste os fluxos que importam, não a página de entrada: inicie sessão, navegue por cada função necessária, carregue ficheiros se a aplicação o fizer, deixe a sessão prevista expirar e siga cada caminho de saída. Uma página que é renderizada uma vez não é prova de que a aplicação funciona.

Quando um fluxo necessário não pode ser reescrito, passe para um desenho documentado de federação, proxy inverso ou acesso de rede. Um portal de navegador ao qual se pede que se comporte como um túnel geral passará a demonstração e falhará a auditoria.