As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Configuração única de um aplicativo de federação direta do IAM no Okta 1. Uma conta da Okta com a qual você possa fazer login como usuário com permissões administrativas. 1. No Okta Admin Console, em **Applications**, escolha **Applications**, 1. Escolha **Browse App Catalog**. Pesquise e escolha **AWS Account Federation**. Escolha **Add integration**. 1. Configure a federação direta do IAM AWS seguindo as etapas em [Como configurar o SAML 2.0 para federação de AWS contas](https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Amazon-Web-Service.html). Para lidar com cenários de falha regional, ao configurar o endpoint de login, recomendamos que você habilite o endpoint não regional e vários endpoints regionais para todas as regiões em que você opera para melhorar a resiliência da federação. Ao configurar o URL do ACS para esse acesso de emergência, recomendamos que você use o endpoint regional de uma região diferente daquela em que seu IAM Identity Center está implantado. Consulte os [endpoints de login na](https://docs.aws.amazon.com/general/latest/gr/signin-service.html) *Referência AWS geral* para obter a lista de endpoints regionais. 1. Na guia **Sign-On Options**, selecione SAML 2.0 e insira as configurações de **Group Filter** e **Role Value Pattern**. O nome do grupo para o diretório do usuário depende do filtro que você configura. ![\[Duas opções: accountid e perfil no filtro de grupo ou padrão de valores de perfil.\]](http://docs.aws.amazon.com/pt_br/singlesignon/latest/userguide/images/emergency-access-group-filter-role-value-pattern.png) Na figura acima, a `role` variável é para o perfil de operações de emergência em sua conta de acesso de emergência. Por exemplo, se você criar a `EmergencyAccess_Role1_RO` função (conforme descrito na tabela de mapeamento) em Conta da AWS `123456789012`, e se a configuração do filtro de grupo estiver configurada conforme mostrado na figura acima, o nome do seu grupo deverá ser`aws#EmergencyAccess_Role1_RO#123456789012`. 1. Em seu diretório (por exemplo, seu diretório no Active Directory), crie o grupo de acesso de emergência e especifique um nome para o diretório (por exemplo, `aws#EmergencyAccess_Role1_RO#123456789012`). Atribua seus usuários a esse grupo usando seu mecanismo de provisionamento existente. 1. Na conta de acesso de emergência, [configure uma política de confiança personalizada](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) que forneça as permissões necessárias para que o perfil de acesso de emergência seja assumido durante uma interrupção. Veja a seguir um exemplo de declaração de uma **política de confiança** personalizada anexada ao `EmergencyAccess_Role1_RO` perfil. Para ver uma ilustração, consulte a conta de emergência no diagrama em [Como criar um mapeamento emergencial de funções, contas e grupos](emergency-access-mapping-design.md). Substitua o exemplo de ARN do provedor SAML pelo correto que você criou na conta de acesso de emergência. Substitua os endpoints regionais no exemplo pelas regiões de sua escolha. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect":"Allow", "Principal":{ "Federated":"arn:aws:iam::123456789012:saml-provider/[SAML PROVIDER NAME]" }, "Action":[ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Condition":{ "StringEquals":{ "SAML:aud": [ "https://signin.aws.amazon.com/saml", "https://us-west-2.signin.aws.amazon.com/saml", "https://us-west-1.signin.aws.amazon.com/saml", "https://us-east-2.signin.aws.amazon.com/saml" ] } } }, { "Effect":"Allow", "Principal":{ "Federated":"arn:aws:iam::123456789012:saml-provider/Okta" }, "Action":"sts:SetSourceIdentity" } ] } ``` ------ 1. Veja a seguir um exemplo de declaração de uma **política de confiança** personalizada anexada ao perfil `EmergencyAccess_Role1_RO`. Para ver uma ilustração, consulte a conta de emergência no diagrama em [Como criar um mapeamento emergencial de funções, contas e grupos](emergency-access-mapping-design.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/EmergencyAccess_RO", "arn:aws:iam::444455556666:role/EmergencyAccess_RO" ] } ] } ``` ------ 1. Nas contas de workload, configure uma política de confiança personalizada. Veja a seguir um exemplo de declaração de uma **política de confiança** personalizada anexada ao perfil `EmergencyAccess_RO`. Neste exemplo, a conta `123456789012` é a conta de acesso de emergência. Para ver uma ilustração, consulte a conta de workload no diagrama abaixo [Como criar um mapeamento emergencial de funções, contas e grupos](emergency-access-mapping-design.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam::123456789012:root" }, "Action":"sts:AssumeRole" } ] } ``` ------ **nota** A maioria IdPs permite que você mantenha a integração de aplicativos desativada até que seja necessária. Recomendamos que você mantenha o aplicativo de federação direta do IAM desativado em seu IdP até que seja necessário para acesso de emergência.