Este método permite que a autenticação Shibboleth seja acionada somente quando necessária. <Location /aplicacao/login.php>
AuthType shibboleth ShibRequireSession On require valid-user </Location>
Neste exemplo apenas a página login.php é protegida pelo Shibboleth. As outras páginas da aplicação não têm esse requisito.
Essa forma é também interessante em casos onde vários métodos de autenticação são suportados; a página em questão seria apenas uma forma de criar a sessão do usuário com atributos provindos da autenticação shibboleth. Outras partes do sistema podem requerer apenas que exista uma sessão estabelecida para o usuário ou podem ser, ainda, públicas. Por suportar bem outros tipos de autenticação, é uma das soluções mais indicadas.
Lazy sessions
q
1 Proteção via regras baseadas na URL do recurso. 1 Verificação de sessão pelas variáveis de ambiente. 1 Redirecionamento explícito para SessionInitiator.
1 O controle de acesso fica completamente por conta da aplicação.
1 Url: https://servidor/Shibboleth.sso/Login?target:”http://servidor/applicacao”.
Lazy sessions é muito usado quando um site possui acesso público e privado para os mesmos recursos. É útil para aplicações dinâmicas que tipicamente desejam oferecer um modo “guest” por padrão e iniciar um login de usuário apenas quando escolhido pelo usuário.
Funciona da seguinte forma: o recurso é protegido por Shibboleth, mas não requer uma sessão ativa. Assim, as requisições passam normalmente, mas se o usuário não foi auten- ticado, as variáveis de ambiente ou cabeçalhos HTTP não são mapeados. A aplicação faz a verificação da presença de tais informações (atributos personalizados, REMOTE_USER etc.) para decidir pela autorização ou não.
Quando o usuário deseja criar sua sessão, a aplicação deve disparar explicitamente um redire- cionamento HTTP para a URL indicada pelo handler de SessionInitiator com alguns parâmetros. Usado em:
1 Aplicações que têm funcionalidades que não necessitam de sessão de usuário todo o tempo; 1 Aplicações que suportam vários mecanismos de autenticação.
Ca pí tu lo 5 - A pl ic aç õe s F ed er ad as <Location /aplicacao> AuthType shibboleth ShibRequireSession Off require shibboleth </Location>
Proxy reverso
Única opção viável para uma aplicação proprietária onde o método de autenticação não pode ser adaptado ao Shibboleth.
Shibboleth SP mod_proxy apache Aplicação
O método de proxy reverso é usado quando a aplicação não suporta autenticação Shibboleth nativamente. Aplicações JEE são o caso típico. Nesse cenário, todas as cha- madas são interceptadas pelo servidor Apache, que então repassa as chamadas para a aplicação. No caso de aplicações JEE, esse repasse é feito via protocolo AJP.
Única opção viável para uma aplicação proprietária onde o método de autenticação não pode ser adaptado ao Shibboleth.
ProxyPass /app http://Servidor/app <Location /app>
AuthType shibboleth ShibRequireSession ON require shibboleth </Location>
O método de proxy reverso é usado quando a aplicação não suporta autenticação Shibboleth nativamente. Aplicações JEE são o caso típico.
Nesse cenário, todas as chamadas são interceptadas pelo servidor Apache, que então repassa as chamadas para a aplicação.
No caso de aplicações JEE, esse repasse é feito via protocolo AJP.
Atributos e mapeamentos
q
Atributos:
1 Representam informações relativas ao usuário como nome, e-mail, filiação etc. 1 Podem ser disponibilizados pelo SP para a aplicação através de variáveis de ambiente
ou cabeçalhos http.
1 As aplicações podem utilizá-los para realizar a autorização de usuários. Figura 5.3
Protegendo aplicação com Proxy Reverso.
Fe de ra çã o C AF e : P ro ve do re s d e S er vi ço s e A pl ic aç õe s F ed er ad as
Os cabeçalhos HTTP são inseguros, pois são podem ser gerados a partir do navegador web, podendo ser forjados. As variáveis de ambiente web são disponibilizadas à aplicação direta- mente pelo servidor, impedindo essa possível falsificação.
Variáveis de ambiente web são padrão no Shibboleth2. Nem todos os servidores suportam variáveis de ambiente web, como é o caso do IIS.
q
Mapeamentos:
1 Definem o nome de cabeçalho ou variável de ambiente web para cada nome de atributo. 1 São configurados no SP pelo arquivo attribute-map.xml.
1 Exemplo de um mapeamento para o atributo “cn”:
<Attribute name=”urn:mace:dir:attribute-def:cn” id=”ShibCafe- -Person-cn”/>
<Attribute name=”urn:oid:2.5.4.3” id=”ShibCafe-Person-cn”/> 1 O atributo name da tag Attribute representa um espaço de nome universal.
1 O atributo id define o nome do cabeçalho HTTP ou variável de ambiente web a ser forne- cida pelo SP.
1 Utilizam-se duas tags para manter compatibilidade entre os protocolos SAML1 e SAML2.
Autorização via aplicação
q
1 A estrutura Shibboleth autentica o usuário e fornece os atributos para a aplicação. 1 A aplicação é responsável pela autorização.
1 Nem a aplicação, nem o servidor HTTP manipulam a senha do usuário. 1 Há necessidade de atributos comuns/compatíveis entre os IdPs para uma
autorização global.
Após a autenticação, o Provedor de Serviços (SP) pode solicitar ao Provedor de Iden- tidades (IdP) atributos do usuário. De acordo com a política de liberação de atributos acordada entre IdP e SP, os atributos podem ser liberados para que o SP repasse para a aplicação. A aplicação, de posse desses atributos, pode utilizá-los para controle de acesso dos usuários. Para que a autorização seja global (para todos os usuários da aplicação), é necessário que todos possuam atributos em comum que deverão ser utilizados na autori- zação de acesso aos recursos.
Ca pí tu lo 5 - A pl ic aç õe s F ed er ad as IdP A
Estudantes (autorizados) Professores Téc. Administrativos
IdP B
IdP C
SP Regra:
Afiliação: estudante
O que fazer se os usuários não possuírem atributos em comum? Algumas possíveis soluções:
1 Criar atributos em comum;
1 Usar GMT para criação de grupos federados;
1 Usar Unique ID ou email para autorização (autorização individualizada no SP).
q
Atributos disponibilizados pelo esquema brEduPerson que podem ser utilizados para a autorização:
1 brEduAffiliationType
2 Tipo de vinculo com a instituição. 1 brEntranceDate
2 Data de início de vínculo. 1 brExitDate
2 Data de fim do vínculo.
A Federação CAFe recomenda a disponibilização de alguns atributos e define seus nomes e semânticas, caso sejam utilizados. Os atributos brEduAffiliationType, brEntranceDate e brExitDate são atributos interessantes para uzar como base para autorização para grandes grupos de usuários. Os tipos de vínculos recomendados no esquema brEduPerson são: 1 Faculty (professores , administradores);
1 Student (estudante); Figura 5.4
Regras de autorização via atributos.
Fe de ra çã o C AF e : P ro ve do re s d e S er vi ço s e A pl ic aç õe s F ed er ad as 1 Staff (pessoal);
1 Position (coordenador etc.);
1 Scholarshipawardee (iniciação, pó ...); 1 Other (contrato de outro tipo).
q
A autorização também pode ser assistida por uma base relacional proporcionando. 1 Maior flexibilidade:
2 Liberdade na criação das regras de autorização. 1 Facilidade de Integração:
2 Maior facilidade no relacionamento com outras bases. 1 Necessidade de manutenção:
2 As regras devem ser criadas e mantidas pela aplicação.
As aplicações podem manter bases adicionais para controle de acesso. Dessa forma, os atributos recebidos no processo de autenticação federada podem servir como chave para busca de autorização na base local. Há um custo adicional para manutenção dessa base, mas muitas vezes isto é necessário.