AWS Federation: Single Account

AWS Single Account를 통해 Okta를 연동하는 초간단 설명서

Okta 공식문서

1. Amazon Web Services Account Federation

2. Connect Okta to single Amazon Web Services instances

3. How to Configure SAML 2.0 for AWS Account Federation

4. Pull up list Role and SAML User Role

주요 사항

• Okta와 연결할 역할을 갖춘 AWS Account 필요합니다.

• 해당 앱은 Okta 계정이 아닌 AWS Account을 통해 로그인합니다.

Ⅰ. Okta-AWS Account 연동

1. SSO 통합 기능

Okta 생성한 AWS Account Federation 앱에 대한 Metadata를 AWS에 등록하고 Okta 관리자는 ARN을 통해 하나 이상의 역할을 AWS에서 리스트를 받아 사용자에게 할당합니다. 하나 이상의 역할을 할당받은 사용자는 사용할 역할을 선택하여 사용할 수 있습니다. Okta 관리자는 Okta를 통해 사용자의 인증된 세션 기간도 설정할 수 있습니다.

SAML 2.0이 구성되면 Okta에서 아래 기능을 제공합니다.

• Okta 대시보드 로그인(IdP initiated SSO)

---

Ⅱ. Okta-AWS Account 연동 구성

1. AWS Single Account

1.1 [Okta] AWS 앱 추가 및 설정

경로: Application ➡ Application ➡ Browse App Catalog ➡ AWS Account Federation ➡ Add integration

1. Application label: AWS Account Fedaration 앱을 할당 받은 사람들의 Dashboard에 보여지는 앱의 이름입니다.

• "View Setup instruction"을 열어놓은 뒤, 다음 단계 설정합니다.

1.2 [AWS] Okta를 IdP로 구성

경로: AWS Console ➡ Identity and Access Management(IAM) ➡ Identity Providers ➡ Create Provider ➡ Save

1. Provider Type: SAML로 구성할 예정이기 때문에 SAML은 선택합니다.

2. Provider Name: AWS에 등록할 IdP 이름을 설정합니다.

Metadata Document기입 방법

1. Metadata document: Okta 서비스를 사용하는 앱과의 연결을 설정하기 위한 정보입니다. Okta에서 제공하는 파일을 XML형태로 저장하여 AWS에 업로드합니다.

• metadata는 View SAML setup instruction 이외에도 아래 경로에서 확인할 수 있습니다.

경로: Application ➡ Application ➡ AWS Account Federation App ➡ Sign on ➡ SAML Signing Certificates ➡ Actions ➡ View IdP metadata

metadata 저장 경로

• Okta IdP 등록이 완료되면 아래와 같은 화면을 볼 수 있습니다.

Okta IdP 등록 완료 화면

다음 구성을 위해 ARN을 복사합니다.

ARN 복사 화면

1.3 [AWS] Okta를 Trusted Source로 등록

1.3.1 기존 역할에 SSO 엑세스 권한을 부여할 경우

경로: Role ➡ Okta SSO 엑세스를 허용할 역할 ➡ Trust relationships ➡ Edit trust policy

• 이전에 구성한 SAML IdP를 사용하여 SSO를 Okta로 허용하도록 신뢰 관계 정책을 수정합니다.

• Identity provider에 등록한 IdP ARN을 넣은 예시입니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "<!!Identity provider에 등록한 IdP ARN를 복사하여 붙여넣습니다!!>"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "SAML:aud": "https://signin.aws.amazon.com/saml"
                }
            }
        }
    ]
}

1.3.2 새 역할에 SSO 엑세스 권한을 부여할 경우

경로: IAM ➡ Access management ➡ Roles ➡ Create role

1. Trusted entity types: SAML 2.0 Federation 선택

2. SAML 2.0 Fedaration: Okta와 연결하기 위해 생성했던 Okta IdP를 선택

• Okta에 부여할 역할을 선택합니다.

• 역할 이름과 설명을 기입하고 Create Role을 클릭합니다.

1.4 [AWS] 연동을 위한 Access Key 생성

경로: AWS Console ➡ IAM ➡ Users ➡ Add users

User name 설정

• Attach policies directly를 클릭한 다음 create policy로 아래 정책을 생성하여 연결합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
          "Effect": "Allow",
          "Action": [
              "iam:ListRoles",
              "iam:ListAccountAliases"
          ],
          "Resource": "*"
        }
    ]
}

경로: Okta와 연결할 IAM User 클릭 ➡ Security credentials ➡ Access key ➡ Create access key

• 생성한 Access key에 대한 "Access key"와 "Secret access key"를 복사합니다.

1.5 [Okta] SAML 2.0 세부 설정

1. Session Duration: 세션의 유효시간을 정할 수 있습니다. 가능한 범위는 900초~43200초입니다.

2. Join all roles: 체크 안했을 때 그룹에 설정된 역할보다 개별 할당된 역할이 우선 부여됩니다. 사용자가 여러 그룹에 할당되 있을 경우, 그룹에 해당된 역할을 전부 부여하고 싶다면 Join all roles를 체크하면 됩니다.

1.6 [Okta] API 통합 설정

• AWS 앱은 사용자 프로비저닝을 지원하지 않습니다.

• 그러나 SAML SSO가 작동하려면 AWS에서 정보를 가져와야하기 때문에 프로비저닝 설정이 필요합니다.

• 앞서 AWS에서 복사한 "Secret Key & Access Key"를 넣어주고 "Test API Credentials"를 클릭하고 API 연결이 되면 저장합니다.

경로: Application ➡ Application ➡ AWS Account Federation ➡ Provisioning ➡ Integration ➡ Enable API Integration

---

III. 앱 할당

1. 사용자

• 사용자에게 앱을 할당할 경우, "SAML User Roles"를 통해서 사용자에게 부여할 역할을 선택해서 부여하면 됩니다.

• 만약 해당 역할을 선택하지 않으면 "Role"에 선택되어있는 역할이 자동 부여됩니다.

2. 그룹

• 역할이 부여되는 기준이 사용자와 동일합니다.

• 그룹에 앱을 할당할 경우, "SAML User Roles"를 통해서 사용자에게 부여할 역할을 선택해서 부여하면 됩니다.

• 만약 해당 역할을 선택하지 않으면 "Role"에 선택되어있는 역할이 자동 부여됩니다.

IV. 최종 사용자 경험

• AWS Account Federation은 무조건 Okta를 통해서만 로그인(IdP initiated SSO)이 가능합니다.

1. 하나의 역할만 부여된 계정의 사용자

2. 여러 역할이 부여된 계정의 사용자