Usando Atributos Fed.: Autorização OAM e Cabeçalhos HTTP

Este artigo descreve como os atributos recebidos nas mensagens SSO SAML/OpenID podem ser usados nas Políticas de Autorização do OAM e como eles podem ser fornecidos para aplicativos Web protegidos.

No runtime, quando o OAM/SP processa com sucesso uma mensagem de Resposta SSO SAML / OpenID, o servidor salva algumas das informações da resposta na sessão do OAM, como atributos que podem ser usados nas políticas de autorização do OAM

Em condições para regras de autorização
Em respostas para fornecer os atributos SAML/OpenID para aplicativos Web protegidos

As informações de Resposta de SSO SAML / OpenID são salvas na sessão do OAM como atributos referenciados pelos seguintes identificadores:

O nome do parceiro IdP, referenciado por $session.attr.fed.partner
O valor NameID da resposta SSO, referenciado por $session.attr.fed.nameidvalue
O formato NameID da resposta SSO, para protocolos SAML, referenciado por $session.attr.fed.nameidformat
Os atributos contidos no AttributeStatement da Asserção SAML ou na Resposta de SSO OpenID, referenciada por $session.attr.fed.attr.ATTR_NAME, com ATTR_NAME sendo
O nome do atributo da sessão local, se um mapeamento de Perfil do Atributo IdP foi aplicado
Ou o nome do atributo da resposta SSO, se nenhum mapeamento de Perfil de Atributo IdP foi aplicado a esse atributo

Visão Geral

Um ambiente típico do OAM é composto por:

diretório LDAP
Servidor administrativo do OAM, com o servidor de runtime do OAM da console de administração do OAM
Aplicativos Web
Agentes WebGate que protegem o aplicativo Web em servidores HTTP (OHS, IIS...)

Quando um usuário autenticado solicita acesso a um recurso protegido:

WebGate intercepta a chamada e garante que o usuário seja autenticado
O usuário está autorizado a acessar o recurso avaliando políticas de autorização para este recurso
WebGate injeta dados, como cookies ou cabeçalhos HTTP, na solicitação HTTP que será encaminhada para o recurso protegido

As Políticas de Autorização do OAM usadas para avaliar se um usuário pode ou não acessar um recurso podem ser baseadas em várias condições:

Identidade: Condição com base na identidade ou grupos de usuários aos quais o usuário pertence
Endereço IP: Condição baseada no endereço IP do usuário
Temporal: Condição baseada no tempo
Atributos: Condição baseada em atributos (LDAP, solicitação HTTP ou atributos de sessão).

Um administrador pode usar os dados da Federação recebidos na mensagem de SSO SAML/OpenID em uma regra de autorização, usando uma condição de atributo que avalia os atributos da Federação.

As Respostas de Autorização do OAM usadas para injetar dados na solicitação HTTP para disponibilizá-los a aplicativos Web protegidos são baseadas em

Atributos LDAP do usuário
Dados da solicitação HTTP
Strings estáticas
Atributos da sessão do OAM

Da mesma forma que as Políticas de Autorização do OAM, um administrador pode injetar dados de federação na solicitação HTTP por meio do uso de atributos de sessão do OAM que fazem referência às entradas de federação ($session.attr.fed.partner, $session.attr.fed.attr.ATTR_NAME…)

Configuração de SSO da Federação

Use a mesma configuração da Federação SAML 2.0 que foi configurada anteriormente, em que:

O OAM atua como um Provedor de Serviços
O IdP (AcmeIdP) envia uma Asserção SAML com
- NameID definido como userID
- Atributos enviados
- email definido como endereço de e-mail do usuário
- fname definido como nome do usuário
- surname definido como o sobrenome do usuário
- title definido como o último cargo do usuário
OAM/SP configurado com um Perfil de Atributo IdP para
- Mapear fname para o nome
- Mapear surname para o sobrenome
- Deixar um email como está

Dois usuários serão usados:

Alice:

userID: alice
e-mail: <alice@oracle.com>
nome: Alice
sobrenome: Appleton
título: gerente

Bob:

userID: sacudir
e-mail: <bob@oracle.com>
nome: Bobby
sobrenome: Smith
título: engenheiro

A Resposta SAML XML com a Asserção enviada de volta pelo IdP é:

<samlp:Response ..>
    <saml:Issuer ...>http://acme.com
/idp</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer ...>http://acme.com /idp</saml:Issuer>
        <dsig:Signature ...>
        ...
        </dsig:Signature>
        <saml:Subject>
            <saml:NameID ...>alice</saml:NameID>
            ...
        </saml:Subject>         <saml:Conditions ...>
         ...
        </saml:Conditions>         <saml:AuthnStatement ...>
        ...
        </saml:AuthnStatement>
        <saml:AttributeStatement ...>
            <saml:Attribute Name="email" ...>
                <saml:AttributeValue
...>alice@oracle.com</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="title" ...>
                <saml:AttributeValue
...>manager</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="surname" ...>
                <saml:AttributeValue
...>Appleton</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="fname" ...>
                <saml:AttributeValue
...>Alice</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

A página Testar SP mostra resultados diferentes, pois o OAM/SP processou os atributos de acordo com as regras em que:

o e-mail não foi alterado
o título não foi alterado
fname foi mapeado para firstname
o sobrenome foi mapeado para o sobrenome

Descrição da ilustração Test_Federation_SSO.jpg

Aplicativo Web Protegido

Neste exemplo, use os seguintes componentes:

OHS está instalado
Um agente WebGate foi configurado para esta instância do OHS
Um Domínio de Aplicativo do OAM foi criado para este WebGate, que protege todos os recursos no servidor do OHS
Política de Autenticação:
- Nome: Política de Recursos Protegidos
- Programa de Autenticação: FederationScheme
Política de Autorização:
- Nome: Política de Recursos Protegidos
- Recursos
- /** e /.../*
- Vinculado à Política de Recursos Protegidos
Política de Autenticação e Política de Autorização da "Política de Recursos Protegida"
O recurso /cgi-bin/printenv no OHS imprime dados ao processar a Solicitação HTTP enviada pelo browser
Cabeçalhos HTTP
Dados da solicitação (caminho, string de consulta...)
Dados do servidor (endereço IP, porta...)

Um exemplo de navegador que acessa o recurso sem ser protegido pelo OAM/WebGate resulta na seguinte exibição (no teste, o aplicativo Web será protegido conforme listado acima):

Descrição da ilustração Protected_web_Application.jpg

Condições de Autorização

O exemplo a seguir mostra como construir uma Política de Autorização usando atributos de Federação armazenados na sessão do OAM para um recurso com as seguintes restrições:

Os usuários são autenticados via SSO de Federação (portanto, o recurso é protegido por meio de uma Política de Autenticação FederationScheme)
O IdPs fornece o título do job do usuário e é conhecido localmente como título (se o IdP enviar o título do job por meio de um nome diferente do título, um Perfil de Atributo IdP precisará ser usado para mapeá-lo para o nome do título local)
Somente usuários com o título de gerente devem ter acesso ao recurso

Para criar essa política de autorização, execute as seguintes etapas:

Vá para a Console de Administração do OAM: http(s)://oam-admin-host:oam-adminport/oamconsole
Navegue até Access Manager, Domínios de Aplicativos
Pesquise e clique no Domínio de Aplicativos do recurso
Clique em Políticas de Autorização
Abra a Política de Autorização que protege o recurso (Política de Recursos Protegidos neste exemplo)
Clique na guia Condições
Clique em Adicionar para definir uma nova condição:
1. Nome: TitleCondition
2. Tipo: Attribute
Clique em Adicionar Selecionada

Descrição da ilustração Add_Condition.jpg

Selecione a condição recentemente criada
Na janela Detalhes da Condição, clique em Adicionar:
- Namespace: Session
- Nome do Atributo: Other
- Informe o nome do atributo: fed.title
- Operador: Equals
- Valor do Atributo: manager
Clique em OK

Descrição da ilustração Add_Attr_Condition.jpg

Clique na tab Regras
Remova a condição TRUE, se presente na Regra de Permissão, Condições Selecionadas
Adicione TitleCondition à Permitir Regra, Condições Selecionadas
Clique em Aplicar

Descrição da ilustração Authorization_Policy.jpg

Para testar, em um novo navegador, acesse o recurso protegido. Você será redirecionado para IdP.

Se você autenticar no IdP com o alice, o browser mostrará o seguinte no final do agora, mostrando o cabeçalho HTTP do Usuário Remoto definido como alice (já que o IdP forneceu o atributo de título definido como gerente e o OAM só permite acesso aos usuários com o atributo de sessão do OAM fed.title definido como gerente):

Descrição da ilustração Document_root.jpg

Se você autenticar no IdP com bob, o browser mostrará o seguinte no final do agora, mostrando um erro (já que o IdP forneceu o atributo de título definido como engenheiro e o OAM só permite acesso aos usuários com o atributo de sessão do OAM fed.title definido como gerente):

Descrição da ilustração OAM_Operation_error.jpg

Injetando atributos de Fed

O exemplo a seguir mostra como injetar atributos SAML / OpenID coletados da resposta SSO como Cabeçalhos HTTP para a Web protegida com as seguintes restrições:

Os usuários são autenticados via SSO de Federação (portanto, o recurso é protegido por meio de uma Política de Autenticação FederationScheme)
O IdPs fornece o título do job do usuário e é conhecido localmente como título (se o IdP enviar o título do job por meio de um nome diferente do título, um Perfil de Atributo IdP precisará ser usado para mapeá-lo para o nome do título local)
O OAM/WebGate está configurado para injetar:
- Endereço de email como endereço de email
- Nome como nome
- Sobrenome

A configuração é feita por meio do uso de objetos Resposta de Autorização em uma definição de Política de Autorização

Para configurar essa política de autorização, execute as seguintes etapas:

Vá para a Console de Administração do OAM: http(s)://oam-admin-host:oam-adminport/oamconsole
Navegue até Access Manager, Domínios de Aplicativos
Pesquisar e clicar no Domínio da Aplicação do recurso
Clique em Políticas de Autorização
Abra a Política de Autorização que protege o recurso (Política de Recursos Protegidos neste exemplo)
Clique na guia Respostas
Clique em Adicionar para criar a entrada do endereço de e-mail:
- Tipo: Header
- Nome: emailaddress
- Valor: $session.attr.fed.attr.email
Clique em Adicionar

Descrição da ilustração Add_Response.jpg
Clique em Adicionar para criar a entrada com o nome:
- Tipo: Header
- Nome: firstname
- Valor: $session.attr.fed.attr.firstname
Clique em Adicionar
Clique em Adicionar para criar a entrada para o sobrenome:
- Tipo: Header
- Nome: lastname
- Valor: $session.attr.fed.attr.lastname
Clique em Adicionar
Clique em Aplicar

Descrição da ilustração ACS_Authorization_Policy.jpg

Para testar, em um novo navegador, acesse o recurso protegido. Você será redirecionado para IdP, em que a autenticação ocorre.

O OAM/WebGate injeta os itens de Resposta de Autorização com base nos atributos da Sessão do OAM (recebidos do IdP) e o aplicativo Web protegido os exibe (minha página de teste exibe um cabeçalho HTTP como HTTP_NAME, com NAME sendo o nome do Cabeçalho HTTP).

Descrição da ilustração Authorization_Response.jpg

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal YouTube do Oracle Learning. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.

Título e Informações de Copyright

Using Fed Attributes- OAM Authorization and HTTP Headers

F61887-01

September 2022