Olá tudo bem?
Hoje iremos fazer mais um post sobre federação, nesse caso entre a Jumpcloud e Oracle Cloud.
Nesse cenário temos usuários criados na Jumpcloud que necessitam ser sincronizados par OCI e consequentemente realizar o acesso federado entre as Clouds.
Esse cenário é muito parecido com o da Azure x OCI e pode auxiliar a manter seu controle de identidade para seu provedor de identidade padrão, nesse caso Jumpcloud
Hoje vamos fazer a federação de identidade e também trabalhar no contexto do SCIM para que os usuários sejam sincronizados automaticamente assim que forem assinados a aplicação de SSO na Jumpcloud.
Passo 1: Criando uma aplicação SSO na Jumpcloud
Procure por Oracle e selecione ela
Depois clique em Next
Na proxima tela você pode customizar o nome, logomarca, depois que realizar as alterações clique em Save Application
Após salvar, clique em Configure Application
Passo 2 – Configurando a aplicação na Jumpcloud
Nessa etapa, iremos primeiro coletar os dados da Oracle Cloud para configurar a aplicação na Jumpcloud, o primeiro ponto é fazer o download do metadados do seu domínio (Domain) em Oracle.
Existem algumas formas de se realizar esse processo, eu vou apresentar a forma de realizar via URL de metadados do Domain.
Primeiro acesse seu domain em Oracle Cloud e navegue até Settings
Habilite essa opção e depois ao final da tela clique em save
Agora, para fazer o download do seu xml de metadados, você precisa voltar ao seu domínio e coletar o ID do seu Domain
Cole essa URL no bloco de notas, você terá um valor parecido com o abaixo, cada domain possui seu ID, você precisa coletar o seu, o valor abaixo é um exemplo para referência
https://idcs-3c78954269a1249bc82ce956bdd01c9bc.identity.oraclecloud.com:443O valor em negrito é seu ID do IDCS, para fazer o download do metadados, você precisa substituir nessa url abaixo aonde está <idcs-id> com o seu id
https://<idcs-id>.identity.oraclecloud.com/fed/v1/metadataA url ficará assim:
https://idcs-3c78954269a1249bc82ce956bdd01c9bc.identity.oraclecloud.com/fed/v1/metadataCole essa URL no navegador e você verá um arquivo XML do Metadados do seu domínio, clique com o botão direito no centro da tela e salve o metadados em seu computador
Você pode depois que fazer o download do metadados, desabilitar a opção em Settings > Configure client access
Com o xml do metadados em mãos, volte para a aplicação que iniciou a configuração na jumpcloud e faça o upload do metadados
Você vai reparar que ele vai preencher todas as opções com as informações do seu tenancy que estavam presentes no metadados, só terá 1 que você precisará configurar
- SP Entity ID: ele irá preencher automaticamente, não precisa alterar
- Login URL: ele irá montar uma url de exemplo, você precisa alterar a url trocando as informações YOUR_REGION e YOUR_TENANT_ID para os seus dados, onde:
https://console.YOUR_REGION.oraclecloud.com/?tenant=YOUR_TENANT_ID
YOUR_REGION: é Home Region do seu tenancy, exemplo: sa-saopaulo-1, sa-vinhedo-1, us-ashburn-1, troque para sua opção
YOUR_TENANT_ID: é o seu cloud account name, o nome do tenancy, normalmente você usa ele como na imagem abaixo:
Ele deve ser alterado e ficará parecido com esse:
https://console.sa-saopaulo-1.oraclecloud.com/?tenant=wrmedici
- IDP URL: ele irá preencher automaticamente, não precisa alterar, mas copie e salve em um bloco de notas pois irá usar posteriormente
Na parte de atributos, deixe como está o exemplo abaixo
Depois salve as alterações.
Passo 3 – Configurando o IdP em Oracle Cloud
Depois que salvou, abra novamente a aplicação e navegue até a Aba SSO, salve o metadados do provedor de identidade na Jumpcloud
Agora com o xml do metadados do Jumpcloud salvo, vamos para Oracle Cloud
Acesse seu Domain depois clique em Security e por fim em Identity Providers, adicione um IdP do tipo SAML
Na primeira tela, dê um nome (obrigatório), descrição e icone (opcionais) e clique em Next
Na parte de Exchange Metadata, faça o Upload do metadados que você fez download da Jumpcloud e clique em Next
Na tela de Map user identity, altere para que o Request name ID format seja para Email Address e deixe as demais opções como padrão.
Vou alterar para email pois a autenticação que eu vou fazer sempre será e-mail, e é assim lá na Jumpcloud
Depois que finalizar, ele irá para uma tela de resumo e você pode clicar em Create IdP
Por fim, você pode para faciliar o processo clicar em Activate e depois Add to IdP Policy
Quando você clicar em Add to IdP Policy, ele irá redirecionar você para a tela de IdP Policies, acesse a política
Edite a política e adicione a Jumpcloud como uma forma de autenticação
Se você for acessar via Oracle, ele irá apresentar o botão de SSO após adicionar a opção acima para que você consiga autenticar na Jumpcloud
Porém, ainda não irá funcionar por 2 motivos e precisaremos fazer uma configuração adicional.
Fizemos inicialmente a configuração do IdP, porém ainda não colocamos nenhum usuário ou grupo permitido para acessar a aplicação na Jumpcloud e também não temos esses mesmos usuários em OCI.
Por mais que eu já tenha criado um apontamento para um provedor de identidade externo via SAML, a Oracle Cloud não irá deixar você autenticar se não souber quem você é, e só deixará você autenticar se seu usuário estiver no minimo criado em Oracle Cloud.
Queremos que o processo seja automático, por isso agora, iremos fazer uma etapa que irá nos auxiliar nesse processo.
Passo 4 – Sincronizando Grupos e Usuários para Oracle Cloud
Como comentado no final do passo anterior, para que a Oracle permita uma autenticação precisamos que o objeto exista, ou seja, que a conta de usuário exista em OCI.
Para atender esse requisito podemos usar o contexto de SCIM (System for Cross-Domain Identity), que no nosso caso irá auxiliar no cruzamento das informações sincronizando os usuários e grupos da Jumpcloud para OCI
Ao final do artigo eu explico um pouco mais o contexto de permissão, nesse momento o que precisamos entender é que a expectativa para o funcionamento será que de que quando um grupo de usuários seja adicionado a aplicação na Jumpcloud automaticamente ele seja sincronizado para OCI, de forma autônoma, sem precisar de nenhuma ação manual, da mesma forma que se um usuário for adicionado a um grupo que já esteja com ciclo de sincronização configurada, ele seja enviado para OCI e adicionado ao grupo.
Como disse, o contexto da importância do grupo eu irei tratar ao final falando um pouco de permissões.
Bom, sem muita enrolação vamos ao que interessa.
Em Oracle Cloud agora, no seu Domain, clique em Integrated Applications
Vamos adicionar uma Aplicação do tipo Confidential
Na primeira etapa, dê um nome para a aplicação e ao final da tela habilite a opção Enforce grants as authorization, clique em Next
Na próxima etapa, habilite a opção Client Configuration e selecione a opção Client Credentials, navegue até o final da página e adicione uma App Role para User Administrador e clique em Next
Em policy deixe como está por padrão, clique em Finish
Ao fim ative a aplicação
Agora precisamos gerar um Token Key que será utilizado no Identity Management da Jumpcloud
Para gerar um token, iremos usar essa própria aplicação que foi criada utilizando o Client ID e Secret dela em uma conversão do modelo Base 64
Existem algumas formas de realizar a conversar no modelo Base64, eu irei usar o próprio Cloud Shell da OCI para esse procedimento.
Colete o Client ID e secret da aplicação, cole em um Notepad
Agora, com as informações em mão, monte da seguinte forma o comando
echo -n <clientID>:<clientsecret> | base64 --wrap=0Troque o <clientID> e o <clientsecret> pelos seus valores, ele deverá ficar dessa forma, exemplo:
echo -n 7ba565130fe74479a0b2ed7afff893cf:idcscs-0375e1d4-aafa-474c-8862-06e906ddedf9 | base64 --wrap=0Cole no Cloud Shell e clique em Enter
Ele vai gerar um número grande, que aqui no exemplo vai até antes de chegar no meu usuário, copie esse valor
Você também pode usar o base64encode caso prefiraBase64 Encode and Decode – Online
Com o valor do token, cole em um notepad e agora vamos montar a Base URL, ela basicamente é nesse formato:
https://<idcs-id>.identity.oraclecloud.com/admin/v1Lembra o IDCS id utilizado para montar a URL para pegar o metadados da Oracle Cloud, esse mesmo IDCS ID será utilizado para montar a URL de autorização e ela ficará da seguinte forma, como no exemplo:
Lembre-se que cada Domain tem seu próprio IDCS ID, dessa forma colete seu IDCS ID e substitua
https://idcs-3c78954269a1249bc82ce956bdd01c9bc.identity.oraclecloud.com/admin/v1Com os 2 dados coletados, Token e a Base URL, voltaremos para a Jumpcloud e acessaremos a aplicação, na aba Identity Management
Nessa aba, clique na opção Configure e cole o seu Base URL e seu Token nos campos indicados e clique em Activate
Estando tudo correto, ele irá apresentar uma mensagem de confirmação
Clique em Save
Passo 5 – Validando a sincronização
Agora, precisamos validar se a sincronização está funcionando corretamente, para isso eu preciso adicionar usuários ou grupos a aplicação an Jumpcloud
Quando eu adicionar esses grupos que contém usuários a aplicação deve ser capaz de provisionar esses usuários em Oracle Cloud
Inicialmente não temos nenhum usuário ou grupo adicional no meu domínio usado para esse artigo em OCI
Também não tenho nenhum usuário ou grupo adicionado a minha aplicação na Jumpcloud
Vou adicionar o Grupo JumpCloud-Users, que contem 1 usuário para que ele seja sincronizado e possa acessar a Oracle Cloud
Após fazer isso, instantâneamente o usuário e grupo é sincronizado para Oracle Cloud
Se você reparar, o usuário é sincronizado já dentro de um grupo, e isso é muito importante devido a configurações de políticas futuras
Passo 6: Ativando o Federated:Yes nos usuários sincronizados
Um usuário quando está sendo sincronizado de outro provedor de identidade para OCI deve ser enviado com pelo menos 1 atributo e que tem a seguinte função:
- Fedetated: Deve ser enviado do provedor de identidade de origem como Yes. Isso deve ocorrer pois é a garantia que o usuário não consiga acessar a Oracle Cloud localmente e nem trocar a senha local, sem passar pelo provedor de identidade da origem. Uma função de extrema importância para garantir a segurança na federação
Quando sincronizado, esse atributo exemplo da imagem abaixo, nos usuários deve vir com Yes, no exemplo ele será enviado como No, e isso faria com que os usuários pudessem fazer alterações de senha e também autenticar localmente sem passsar pela Jumpcloud
Eu realizei uma série de testes até o presente momento na Jumpcloud usando o contexto de Constant dentro da aplicação que está integrada a Oracle Cloud. Foram configurados diversos modelos de atributos na tentativa de ele enviar a informação com o dado esperado mas sem sucesso.
Com isso, temos que realizar um “ajuste técnico” para garantir a segurança do ambiente antes de finalizar todo o processo de autenticação.
Vamos utilizar o Oracle CLI como exemplo para realizar a alteração do atributo Federated para OCI.
Você pode inicialmente executar um comando para listar todos os usuários e atributos via Cloudshell, alterando os campos em negrito com as suas informações, por exemplo:
oci identity-domains users list --endpoint https://idcs-xxxxxx.identity.oraclecloud.com --query "data.resources[].{UserName: \"display-name\" , UseriD: \"ocid\", IsFederated: \"urn-ietf-params-scim-schemas-oracle-idcs-extension-user-user\".\"is-federated-user\"}" --output tableOnde:
oci identity-domains user list: Este comando é usado para listar todos os usuários em um Identity Domain (Domínio de Identidade) da OCI (Oracle Cloud Infrastructure).
–endpoint: A URL do endpoint (ponto de extremidade) do domínio de identidade é fornecida para especificar o domínio que está sendo consultado.
–query “data.Resources[].{UserName: “displayName”, UseriD: “ocid”, IsFederated: “urn-ietf-params-scim-schemas-oracle-idcs-extension-user-user”.”is-federated-user”}”
A consulta JMESPath é usada para filtrar a saída.
- UserName: Representa o nome de exibição do usuário (Display Name).
- UserID: OCID (Oracle Cloud Identifier) do usuário.
- IsFederated: Representa o atributo isFederatedUser, que indica se o usuário é federado (ou seja, se vem de uma identidade externa, como AD, IDP, etc.).
–output table: Queremos exibir a saída em formato de tabela, tornando-a mais fácil de ler.
Ao executar o comando, veja que ele me exibe a lista dos usuários e mostra os atributos, como só tenho 1, veio dessa forma
Como eu preciso que o meu usuário, cujo ocid foi apresentado seja alterado, eu posso executar o seguinte comando abaixo, alterando os campos em negrito com as informações relacionadas ao seu cenário.
oci identity-domains user patch --user-id ocid1.user.oc1..axxxxxxqqq --schemas '["urn:ietf:params:scim:api:messages:2.0:PatchOp"]' --operations '[{"op": "replace", "path": "urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User:isFederatedUser", "value": true},{"op": "replace", "path": "urn:ietf:params:scim:schemas:oracle:idcs:extension:capabilities:User:canUseConsolePassword", "value": false}]' --endpoint https://idcs-xxxxxxx.identity.oraclecloud.comoci identity-domains user patch: Este comando é usado para modificar atributos de um usuário aplicando uma operação de patch (atualização parcial).
–user-id “<user_ocid>”: Substitua <user_ocid> pelo OCID do usuário que você deseja modificar. Esse OCID pode ser obtido na saída do comando de listagem anterior.
–schemas: Especifica o schema SCIM para uma operação de patch (urn:ietf:params:scim:api:messages:2.0:PatchOp).
–operations: Define a lista de operações que serão aplicadas:
- op: “replace”: Indica que o atributo será substituído ou atualizado.
- path: Especifica o caminho do atributo:
- “urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User:isFederatedUser”: Define o atributo isFederatedUser como true (verdadeiro).
- “urn:ietf:params:scim:schemas:oracle:idcs:extension:capabilities:User:canUseConsolePassword”: Define o atributo canUseConsolePassword como false (falso).
- value: Representa o novo valor para cada atributo.
–endpoint: Especifica o endpoint (ponto de extremidade) do domínio de identidade onde a atualização será aplicada.
Ao executar o comando a flag do usuário é alterada, já no console.
Se você consultar novamente via Cloudshell o usuário também aparecerá com essa flag alterada
Com isso, mesmo que o usuário tente logar localmente no console, ele receberá uma mensagem de erro, conforme exemplo abaixo:
Adicionalmente, você pode alterar a política de logon, caso tenha já um MFA no provedor de identidade Federado, para evitar que o MFA seja solicitado duas vezes, seguindo essa documentação oficial da Oracle
https://docs.oracle.com/pt-br/learn/oci-iam-mfa-federatedusers
E as Políticas Welton? As permissões?
Tem uma regra importante ao final de tudo isso. Um usuário criado em Oracle Cloud por padrão não terá nenhuma permissão, por mais que ele consiga autenticar no console se você não liberar as permissões adequadas.
Depois que você sincronizar seus usuários e grupos, você deve criar Políticas de acesso baseados nas permissões que cada usuário deve ter no console.
Vou deixar 2 links oficiais da Oracle para auxiliar nesse contexto, e que irão te dar uma visão do que é necessário para depois de acessar, conseguir realizar as tarefas em OCI.
Com isso, terminamos esse artigo, espero que seja útil e qualquer dúvida estou a disposição
Obrigado!