Protegendo apps front-end

Se você estiver usando um aplicativo baseado em navegador, poderá usar o fluxo Open ID Connect(OIDC) / OAuth 2.0 authorization_grant para autenticar seus usuários. Quando um usuário não autenticado é detectado, ele é redirecionado automaticamente para a página de autenticação. Após a conclusão da autenticação, o navegador é redirecionado para um terminal /oidc/callback implícito no qual o Adapter intercepta a solicitação. Em seguida, o Adapter obtém os tokens do provedor de identidade e redireciona o usuário novamente para a URL originalmente solicitada.

Para visualizar as informações de sessão do usuário, incluindo os tokens de sessão, é possível consultar o cabeçalho Authorization.

Authorization: Bearer <accessToken> <IDToken>

Também é possível efetuar logout de usuários autenticados. Quando um usuário autenticado acessa qualquer terminal protegido com oidc/logout anexado, conforme mostrado no exemplo a seguir, ele é desconectado.

https://myhost/path/oidc/logout

Se necessário, um token de atualização pode ser usado para adquirir automaticamente novos tokens de acesso e identidade sem que o usuário precise se autenticar novamente. Se o provedor de identidade configurado retornar um token de atualização, ele será persistido na sessão e usado para recuperar novos tokens quando o token de identidade expirar.

Protegendo apps back-end

O adaptador pode ser usado em colaboração com o OAuth 2.0 Fluxo do portador JWT para proteger APIs de serviço validando tokens de portador JWT. O fluxo de autorização do Bearer espera que uma solicitação contenha um Cabeçalho de autorização com um token de acesso válido e um token de identidade opcional. A estrutura do cabeçalho esperada é Authorization=Bearer {access_token} [{id_token}]. Os clientes não autenticados recebem de retorno um status de resposta HTTP 401 com uma lista dos escopos que são necessários para obter autorização. Se os tokens forem inválidos ou expirados, a estratégia de API retornará uma resposta HTTP 401 com um componente de erro opcional que dirá Www-Authenticate=Bearer scope="{scope}" error="{error}".

Para obter mais informações sobre tokens e como eles são usados, consulte Entendendo tokens.

Definindo uma configuração

Dependendo se você estiver protegendo aplicativos front-end ou back-end, crie uma configuração de política com uma das opções a seguir.

• Para aplicativos front-end: os aplicativos baseados em navegador que requerem autenticação do usuário podem ser configurados para usar o fluxo de autenticação OIDC/OAuth 2.0. Para definir um CRD OidcConfig que contenha o cliente usado para facilitar o fluxo de autenticação com o Provedor de identidade, use o exemplo a seguir como um guia.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: OidcConfig
  metadata:
     name:      oidc-provider-config
     namespace: sample-namespace
  spec:
     discoveryUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/.well-known/openid-configuration
     clientId:     <clientID>
     clientSecret: <randomlyGeneratedClientSecret>
     clientSecretRef:
           name: <nameOfKubeSecret>
           key: <keyInKubeSecret>
  

  Explicação dos componentes do arquivo de configuração YAML

  Campo	Tipo	Obrigatório	Descrição
  discoveryUrl	string	True	Um terminal conhecido que fornece um documento JSON de informações de configuração do OIDC/OAuth 2.0.
  clientId	string	True	Um identificador para o cliente que é usado para autenticação.
  clientSecret	string	*Não	Um segredo de texto sem formatação que é usado para autenticar o cliente. Se não fornecido, um clientSecretRef deverá existir.
  clientSecretRef	objeto	Não	Um segredo de referência que é usado para autenticar o cliente. A referência pode ser usada no lugar do clientSecret.
  clientSecretRef.name	string	True	O nome do Segredo do Kubernetes que contém o clientSecret.
  clientSecretRef.key	string	True	O campo dentro do Segredo do Kubernetes que contém o clientSecret.

• Para aplicativos de back-end: A especificação de token de portador OAuth 2.0 define um padrão para proteger APIs usando JSON Web Tokens(JWTs). Usando a configuração a seguir como um exemplo, defina um CRD JwtConfig que contenha o recurso de chave pública, que é usado para validar assinaturas de token.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: JwtConfig
  metadata:
     name:      jwt-config
     namespace: sample-app
  spec:
     jwksUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/publickeys
  

Registrando terminais do aplicativo

Registre os terminais do aplicativo dentro de um CRD Policy para validar solicitações recebidas e cumprir regras de autenticação. Cada Policy se aplica exclusivamente ao namespace do Kubernetes no qual o objeto vive e pode especificar os serviços, caminhos e métodos que deseja proteger.

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
  name:      samplepolicy
  namespace: sample-app
spec:
  targets:
    -
      serviceName: <svcSampleApp>
      paths:
        - exact: /web/home
          method: ALL
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              rules:
                - claim: scope
                  match: ALL
                  source: access_token
                  values:
                    - appid_default
                    - openid
                - claim: amr
                  match: ANY
                  source: id_token
                  values:
                    - cloud_directory
                    - google

        - exact: /web/user
          method: GET
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              redirectUri: https://github.com/ibm-cloud-security/app-identity-and-access-Adapter
        - prefix: /
          method: ALL
          policies:
            -
              policyType: jwt
              config: <jwtConfig>

Adaptador

Para ver os logs do Adapter, é possível usar kubectl ou acessar o pod appidentityandaccessAdapter por meio do console do Kubernetes.

alias Adapter_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=appidentityandaccessAdapter -o jsonpath='{.items[0].metadata.name}')"
Adapter_logs | jq

Mixer

Se o Adaptador não parecer receber as solicitações, verifique os logs do Mixer para assegurar que ele tenha se conectado com sucesso ao Adaptador.

alias mixer_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=telemetry -o jsonpath='{.items[0].metadata.name}') -c mixer"
mixer_logs | jq