Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Configurazione una tantum di un'applicazione federativa IAM diretta in Okta 1. Accedi al tuo Okta account come utente con autorizzazioni amministrative. 1. In Okta Admin Console, in **Applicazioni**, scegli **Applicazioni**. 1. Scegli **Sfoglia il catalogo delle app**. Cerca e scegli **AWS Account Federation**. Quindi scegli **Aggiungi integrazione**. 1. Configura la federazione IAM diretta AWS seguendo i passaggi in [Come configurare SAML 2.0 per la federazione AWS degli account](https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Amazon-Web-Service.html). Per gestire gli scenari di errore regionali, quando configuri l'endpoint di accesso, ti consigliamo di abilitare sia l'endpoint non regionale che gli endpoint regionali multipli per tutte le regioni in cui operi per migliorare la resilienza della federazione. Quando configuri l'URL ACS per questo accesso di emergenza, ti consigliamo di utilizzare l'endpoint regionale di una regione diversa da quella in cui è distribuito il tuo IAM Identity Center. Per l'elenco degli endpoint regionali, consulta gli [endpoint di accesso](https://docs.aws.amazon.com/general/latest/gr/signin-service.html) nel *riferimento AWS generale*. 1. **Nella scheda **Opzioni di accesso, seleziona SAML 2.0 e inserisci le impostazioni **Group Filter** e Role Value Pattern**.** Il nome del gruppo per la directory utente dipende dal filtro configurato. ![\[Due opzioni: accountid e role in group filter o role value pattern.\]](http://docs.aws.amazon.com/it_it/singlesignon/latest/userguide/images/emergency-access-group-filter-role-value-pattern.png) Nella figura precedente, la `role` variabile si riferisce al ruolo delle operazioni di emergenza nell'account per l'accesso di emergenza. Ad esempio, se si crea il `EmergencyAccess_Role1_RO` ruolo (come descritto nella tabella di mappatura) in Account AWS `123456789012` e se l'impostazione del filtro di gruppo è configurata come mostrato nella figura precedente, il nome del gruppo dovrebbe essere`aws#EmergencyAccess_Role1_RO#123456789012`. 1. Nella directory (ad esempio, la directory in Active Directory), create il gruppo per l'accesso di emergenza e specificate un nome per la directory (ad esempio,`aws#EmergencyAccess_Role1_RO#123456789012`). Assegna i tuoi utenti a questo gruppo utilizzando il meccanismo di provisioning esistente. 1. Nell'account di accesso di emergenza, [configura una politica di fiducia personalizzata](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) che fornisca le autorizzazioni necessarie per assumere il ruolo di accesso di emergenza durante un'interruzione. Di seguito è riportato un esempio di dichiarazione per una **politica di fiducia** personalizzata allegata al `EmergencyAccess_Role1_RO` ruolo. Per un'illustrazione, vedi l'account di emergenza nel diagramma seguente. [Come progettare una mappatura di emergenza di ruoli, account e gruppi](emergency-access-mapping-design.md) Sostituisci l'ARN del provider SAML di esempio con quello corretto che hai creato nell'account di accesso di emergenza. Sostituisci gli endpoint regionali dell'esempio con le regioni di tua scelta. ------ #### [ 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. Di seguito è riportato un esempio di dichiarazione per una **politica di autorizzazioni** associata al `EmergencyAccess_Role1_RO` ruolo. Per un'illustrazione, vedi l'account di emergenza nel diagramma seguente. [Come progettare una mappatura di emergenza di ruoli, account e gruppi](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. Negli account del carico di lavoro, configura una politica di attendibilità personalizzata. Di seguito è riportato un esempio di dichiarazione per una **politica di fiducia** allegata al `EmergencyAccess_RO` ruolo. In questo esempio, l'account `123456789012` è l'account di accesso di emergenza. Per un'illustrazione, vedi l'account del carico di lavoro nel diagramma seguente. [Come progettare una mappatura di emergenza di ruoli, account e gruppi](emergency-access-mapping-design.md) ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam::123456789012:root" }, "Action":"sts:AssumeRole" } ] } ``` ------ **Nota** La maggior parte IdPs consente di mantenere l'integrazione di un'applicazione disattivata fino a quando necessario. Ti consigliamo di mantenere disattivata l'applicazione di federazione IAM diretta nel tuo IdP fino a quando non viene richiesta per l'accesso di emergenza.