Eu tenho um aplicativo da web corporativo que se integrará a um serviço de logon único (SSO) por meio da Autenticação integrada do Windows ( IWA). O serviço SSO está fornecendo apenas autenticação (não autorização). Este aplicativo da Web manipulará a autorização por meio de um módulo de autorização customizado. Estamos executando o IIS 6 no Windows 2003.
Depois que um usuário se autenticar via IWA, o IIS, por padrão, executará a página da Web no contexto do usuário que efetuou login. Normalmente, temos um objeto do grupo de segurança do Active Directory que atribuímos permissões de Leitura / Execução ao diretório do site. O objeto de usuário que é um membro desse grupo de segurança designado pode ver / executar a página da web. Qualquer usuário do AD autenticado com êxito no AD, mas não pertence a esse grupo de segurança, obtém um HTTP 401 (acesso negado).
Para este projeto, não queremos ter a manutenção de adicionar / remover objetos de usuário do AD para o grupo de segurança designado. Nosso pensamento é atribuir as permissões de leitura / execução do grupo Authenticated_Users aos arquivos de diretório do site. Dessa forma, se você puder autenticar, você poderá, por padrão, ver / executar a solicitação de página.
Isso é seguro? Do ponto de vista da minha equipe, é seguro, desde que o módulo de autorização neste aplicativo da Web faça seu trabalho.
Alguém mais está fazendo isso ou você tem outra abordagem para gerenciar a autorização ao usar a Autenticação Integrada do Windows no IIS?
Desde que o seu módulo de autorização funcione como anunciado, você não deverá ter problemas. É uma separação frequentemente negligenciada (autenticação e autorização). Você acabou de assumir o ônus de autorização sobre si mesmo (dentro do aplicativo), mas obviamente é o que você quer! Como você disse, tudo que o grupo de segurança do Windows estará fazendo é fornecer um mecanismo de autenticação que não tem nada a ver com permissões reais dentro do seu aplicativo.