SAML 2.0 페더레이션

SAML 2.0 페더레이션 (SAML 2.0 federation)

AWS는 많은 아이덴티티 프로바이더(IdP)가 사용하는 개방 표준인 **SAML 2.0(Security Assertion Markup Language 2.0)**과의 아이덴티티 페더레이션을 지원해요. 이 기능은 페더레이션 **싱글 사인온(SSO)**을 가능하게 해서, 조직의 모든 사람에게 IAM 사용자를 만들지 않아도 사용자가 AWS Management Console에 로그인하거나 AWS API 작업을 호출할 수 있게 해줘요. SAML을 사용하면 커스텀 아이덴티티 프록시 코드를 작성하는 대신 IdP의 서비스를 사용할 수 있으므로 AWS와의 페더레이션 구성 과정을 단순화할 수 있어요.

출처: 문서

본문

참고

IAM SAML 아이덴티티 페더레이션은 SAML 기반 페더레이션 아이덴티티 프로바이더(IdP)의 암호화된 SAML 응답을 지원해요. IAM Identity Center와 Amazon Cognito는 IAM SAML 아이덴티티 프로바이더의 암호화된 SAML 어서션을 지원하지 않아요.

Amazon Cognito user pools로 암호화된 SAML 어서션을 Amazon Cognito identity pool 페더레이션에 간접적으로 추가할 수 있어요. User pool은 IAM SAML 페더레이션과 독립적인 SAML 페더레이션을 가지며 SAML 서명·암호화를 지원해요. 이 기능이 identity pool에 직접 확장되지는 않지만, user pool이 identity pool의 IdP가 될 수 있어요. identity pool에 SAML 암호화를 사용하려면, identity pool의 IdP인 user pool에 암호화가 있는 SAML 프로바이더를 추가하세요.

SAML 프로바이더는 user pool이 제공하는 키로 SAML 어서션을 암호화할 수 있어야 해요. User pool은 IAM이 제공한 인증서로 암호화된 어서션은 받아들이지 않아요.

IAM 페더레이션은 다음 사용 사례를 지원해요.

페더레이션 접근 — 조직의 사용자나 애플리케이션이 AWS API 작업을 호출하도록 허용. 이 사용 사례는 다음 섹션에서 다뤄요. 조직에서 생성된(인증 응답의 일부로) SAML 어서션을 사용해 임시 보안 자격 증명을 얻어요. 이 시나리오는 임시 보안 자격 증명 요청과 OIDC 페더레이션에 설명된 것처럼 IAM이 지원하는 다른 페더레이션 시나리오와 비슷해요. 다만 조직의 SAML 2.0 기반 IdP가 런타임에 인증·인가 확인을 수행하는 많은 세부 사항을 처리해요.
웹 기반 싱글 사인온(SSO) — 조직에서 AWS Management Console로. 사용자는 조직의 SAML 2.0 호환 IdP가 호스팅하는 포털에 로그인하고, AWS로 갈 옵션을 선택하며, 추가 로그인 정보를 제공하지 않고 콘솔로 리다이렉트될 수 있어요. 타사 SAML IdP로 콘솔에 SSO 접근을 확립하거나, 커스텀 IdP를 만들어 외부 사용자에게 콘솔 접근을 활성화할 수 있어요. 커스텀 IdP를 구축하는 방법은 AWS 콘솔에 커스텀 아이덴티티 브로커 접근 활성화를 참고하세요.

다루는 주제

AWS에 대한 API 접근에 SAML 기반 페더레이션 사용
SAML 2.0 기반 페더레이션 구성 개요
SAML 페더레이션 접근을 허용하는 역할 개요
SAML 기반 페더레이션에서 사용자 고유 식별
IAM에 SAML 아이덴티티 프로바이더 생성
신뢰하는 당사자 트러스트로 SAML 2.0 IdP 구성과 클레임 추가
타사 SAML 솔루션 프로바이더를 AWS와 통합
인증 응답용 SAML 어서션 구성
SAML 2.0 페더레이션 프린시펄의 AWS Management Console 접근 활성화
브라우저에서 SAML 응답 보기

AWS에 대한 API 접근에 SAML 기반 페더레이션 사용

직원들이 컴퓨터에서 백업 폴더로 데이터를 복사하는 방법을 제공하려고 한다고 가정해요. 사용자가 컴퓨터에서 실행할 수 있는 애플리케이션을 만들어요. 백엔드에서 애플리케이션은 Amazon S3 버킷의 객체를 읽고 써요. 사용자는 AWS에 직접 접근하지 않아요. 대신 다음 과정이 사용돼요.

조직의 사용자가 클라이언트 앱으로 조직의 IdP에 인증을 요청해요.
IdP가 조직의 아이덴티티 스토어에서 사용자를 인증해요.
IdP가 사용자에 대한 정보를 담은 SAML 어서션을 구성하고 클라이언트 앱에 보내요. IAM SAML IdP에 SAML 암호화를 활성화하면 이 어서션은 외부 IdP가 암호화해요.
클라이언트 앱이 AWS STS AssumeRoleWithSAML API를 호출해 SAML 프로바이더의 ARN, 수임할 역할의 ARN, IdP의 SAML 어서션을 전달해요. 암호화가 활성화되면 클라이언트 앱을 통해 전달되는 어서션은 전송 중에도 암호화된 상태로 유지돼요.
(선택) AWS STS가 외부 IdP에서 업로드한 프라이빗 키로 암호화된 SAML 어서션을 복호화해요.
클라이언트 앱에 대한 API 응답에 임시 보안 자격 증명이 포함돼요.
클라이언트 앱은 임시 보안 자격 증명으로 Amazon S3 API 작업을 호출해요.

SAML 2.0 기반 페더레이션 구성 개요

앞선 시나리오와 그림처럼 SAML 2.0 기반 페더레이션을 사용하려면 먼저 조직의 IdP와 AWS 계정이 서로를 신뢰하도록 구성해야 해요. 이 신뢰를 구성하는 일반적인 과정은 다음 단계에 설명돼요. 조직 안에 Microsoft Active Directory Federation Service(AD FS, Windows Server의 일부), Shibboleth, 또는 다른 호환 SAML 2.0 프로바이더처럼 SAML 2.0을 지원하는 IdP가 있어야 해요.

참고

페더레이션 탄력성을 높이기 위해 IdP와 AWS 페더레이션이 여러 SAML 로그인 엔드포인트를 지원하도록 구성하길 권장해요. 자세한 내용은 AWS Security Blog의 장애 조치를 위한 리전 SAML 엔드포인트 사용 방법 기사를 참고하세요.

조직의 IdP와 AWS가 서로를 신뢰하도록 구성

AWS를 조직의 IdP에 **서비스 프로바이더(SP)**로 등록해요. https://region-code.signin.aws.amazon.com/static/saml-metadata.xml의 SAML 메타데이터 문서를 사용해요.
- 가능한 region-code 값 목록은 AWS Sign-In 엔드포인트의 Region 열을 참고하세요.
- 선택적으로 https://signin.aws.amazon.com/static/saml-metadata.xml의 SAML 메타데이터 문서를 사용할 수 있어요.
조직의 IdP로, AWS에서 그 IdP를 IAM 아이덴티티 프로바이더로 설명할 수 있는 동등한 SAML 메타데이터 XML 파일을 생성해요. 이 파일은 발급자 이름, 생성 날짜, 만료 날짜, 조직의 인증 응답(어서션) 검증에 AWS가 사용할 수 있는 키를 포함해야 해요.
- 외부 IdP에서 암호화된 SAML 어서션을 보내도록 허용한다면, 조직의 IdP로 프라이빗 키 파일을 생성하고 이 파일을 .pem 파일 형식으로 IAM SAML 구성에 업로드해야 해요. AWS STS는 IdP에 업로드된 공개 키에 대응하는 SAML 응답을 복호화하려면 이 프라이빗 키가 필요해요.
- 참고
  SAML V2.0 메타데이터 상호운용성 프로파일 버전 1.0에서 정의한 대로, IAM은 SAML 메타데이터 문서의 X.509 인증서 만료를 평가하거나 조치하지 않아요. 만료된 X.509 인증서가 우려된다면, 조직의 거버넌스·보안 정책에 따라 인증서 만료 날짜를 모니터링하고 인증서를 교체하길 권장해요.
IAM 콘솔에서 SAML 아이덴티티 프로바이더를 만들어요. 이 과정의 일부로 2단계에서 조직의 IdP가 만든 SAML 메타데이터 문서와 프라이빗 복호화 키를 업로드해요. 자세한 내용은 IAM에 SAML 아이덴티티 프로바이더 생성을 참고하세요.
IAM에서 하나 이상의 IAM 역할을 만들어요. 역할의 트러스트 정책에서 SAML 프로바이더를 프린시펄로 설정해, 조직과 AWS 사이의 신뢰 관계를 확립해요. 역할의 권한 정책은 조직 사용자가 AWS에서 무엇을 할 수 있는지 확립해요. 자세한 내용은 제3자 아이덴티티 프로바이더용 역할 만들기를 참고하세요.
- 참고
  역할 트러스트 정책에 사용되는 SAML IdP는 역할과 같은 계정에 있어야 해요.
조직의 IdP에서 조직의 사용자·그룹을 IAM 역할에 매핑하는 어서션을 정의해요. 조직의 서로 다른 사용자·그룹이 서로 다른 IAM 역할에 매핑될 수 있다는 점에 주의하세요. 매핑을 수행하는 정확한 단계는 사용하는 IdP에 따라 달라져요. 앞선 Amazon S3 사용자 폴더 시나리오에서는 모든 사용자가 Amazon S3 권한을 제공하는 같은 역할에 매핑될 가능성이 있어요. 자세한 내용은 인증 응답용 SAML 어서션 구성을 참고하세요.
IdP가 AWS 콘솔에 SSO를 활성화한다면 콘솔 세션의 최대 지속 시간을 구성할 수 있어요. 자세한 내용은 SAML 2.0 페더레이션 프린시펄의 AWS Management Console 접근 활성화를 참고하세요.
만들고 있는 애플리케이션에서 AWS Security Token Service AssumeRoleWithSAML API를 호출해, 3단계에서 만든 SAML 프로바이더의 ARN, 4단계에서 만든 수임할 역할의 ARN, IdP에서 얻은 현재 사용자의 SAML 어서션을 전달해요. AWS는 역할 수임 요청이 SAML 프로바이더에서 참조된 IdP에서 왔는지 확인해요.
- 자세한 내용은 AWS Security Token Service API Reference의 AssumeRoleWithSAML을 참고하세요.
요청이 성공하면 API가 임시 보안 자격 증명 집합을 반환하며, 애플리케이션은 이를 사용해 AWS에 서명된 요청을 보낼 수 있어요. 애플리케이션은 현재 사용자에 대한 정보를 갖고, 앞선 시나리오에서 설명한 것처럼 Amazon S3의 사용자별 폴더에 접근할 수 있어요.

SAML 페더레이션 접근을 허용하는 역할 개요

IAM에서 만드는 역할은 조직의 SAML 페더레이션 프린시펄이 AWS에서 무엇을 할 수 있는지 정의해요. 역할의 트러스트 정책을 만들 때 앞서 만든 SAML 프로바이더를 Principal로 지정해요. 또한 트러스트 정책을 Condition으로 범위를 제한해 특정 SAML 속성과 일치하는 사용자만 역할에 접근하도록 허용할 수 있어요. 예를 들어 SAML 소속(affiliation)이 staff인 (https://openidp.feide.no가 주장한 대로) 사용자만 역할에 접근하도록 허용할 수 있어요. 다음 샘플 정책이 이를 보여줘요.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "saml:aud": "https://us-east-1.signin.aws.amazon.com/saml",
          "saml:iss": "https://openidp.feide.no"
        },
        "ForAllValues:StringLike": {
          "saml:edupersonaffiliation": ["staff"]
        }
      }
    }
  ]
}

(중국 리전용 예시)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws-cn:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "saml:aud": "https://cn-north-1.signin.amazonaws.cn/saml",
                    "saml:iss": "https://openidp.feide.no"
                },
                "ForAllValues:StringLike": {
                    "saml:edupersonaffiliation": ["staff"]
                }
            }
        }
    ]
}

참고

역할 트러스트 정책에 사용되는 SAML IdP는 역할과 같은 계정에 있어야 해요.

정책의 saml:aud 컨텍스트 키는 콘솔에 로그인할 때 브라우저가 표시하는 URL을 지정해요. 이 로그인 엔드포인트 URL은 아이덴티티 프로바이더의 Recipient 속성과 일치해야 해요. 특정 리전의 로그인 URL을 포함할 수 있어요. AWS는 페더레이션 탄력성을 높이기 위해 전역 엔드포인트 대신 리전 엔드포인트를 사용하길 권장해요. 엔드포인트를 하나만 구성하면, 극히 드물게 그 엔드포인트를 사용할 수 없게 되는 경우 AWS로 페더레이션할 수 없어요. 가능한 region-code 값 목록은 AWS Sign-In 엔드포인트의 Region 열을 참고하세요.

다음 예시는 선택적 region-code를 포함한 로그인 URL 형식이에요.

https://region-code.signin.aws.amazon.com/saml

SAML 암호화가 필요하면 로그인 URL에 AWS가 SAML 프로바이더에 할당한 고유 식별자를 포함해야 해요. 이 식별자는 Identity provider 세부 정보 페이지에서 찾을 수 있어요. 다음 예시에서 로그인 URL은 IdP 고유 식별자를 포함하며 로그인 경로에 /acs/를 추가해야 해요.

https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID

역할의 권한 정책에서는 다른 역할처럼 권한을 지정해요. 예를 들어 조직의 사용자가 Amazon Elastic Compute Cloud 인스턴스를 관리하도록 허용된다면, AmazonEC2FullAccess 관리형 정책의 것 같은 Amazon EC2 작업을 권한 정책에서 명시적으로 허용해야 해요.

정책에서 확인할 수 있는 SAML 키에 대한 자세한 내용은 SAML 기반 AWS STS 페더레이션에 사용할 수 있는 키를 참고하세요.

SAML 기반 페더레이션에서 사용자 고유 식별

IAM에서 접근 정책을 만들 때 사용자의 아이덴티티를 기반으로 권한을 지정할 수 있으면 유용할 때가 많아요. 예를 들어 SAML로 페더레이션된 사용자에게 애플리케이션이 Amazon S3에 정보를 다음과 같은 구조로 보관하고 싶을 수 있어요.

amzn-s3-demo-bucket/app1/user1
amzn-s3-demo-bucket/app1/user2
amzn-s3-demo-bucket/app1/user3

버킷(amzn-s3-demo-bucket)과 폴더(app1)는 정적 값이므로 Amazon S3 콘솔이나 AWS CLI로 만들 수 있어요. 하지만 사용자별 폴더(user1, user2, user3 등)는 사용자를 식별하는 값이 페더레이션 과정을 통해 사용자가 처음 로그인할 때까지 알 수 없으므로 코드로 런타임에 만들어야 해요.

리소스 이름의 일부로 사용자별 세부 사항을 참조하는 정책을 작성하려면, 정책 조건에 사용할 수 있는 SAML 키에 사용자 아이덴티티가 있어야 해요. SAML 2.0 기반 페더레이션에 IAM 정책에서 사용할 수 있는 다음 키가 있어요. 다음 키가 반환하는 값으로 Amazon S3 폴더 같은 리소스용 고유 사용자 식별자를 만들 수 있어요.

saml:namequalifier — Issuer 응답 값(saml:iss)과 AWS 계정 ID 및 IAM의 SAML 프로바이더의 친근한 이름(ARN의 마지막 부분)을 포함하는 문자열의 연결에 기반한 해시 값. SAML 프로바이더의 계정 ID와 친근한 이름의 연결은 saml:doc 키로 IAM 정책에 사용할 수 있어요. 계정 ID와 프로바이더 이름은 "123456789012/provider_name"처럼 /로 구분해야 해요. 자세한 내용은 SAML 기반 AWS STS 페더레이션에 사용할 수 있는 키의 saml:doc 키를 참고하세요.
NameQualifier와 Subject의 조합으로 SAML 페더레이션 프린시펄을 고유하게 식별할 수 있어요. 이 값이 계산되는 방법을 보여주는 다음 의사 코드를 참고하세요. 의사 코드에서 +는 연결(concatenation), SHA1은 SHA-1로 메시지 다이제스트를 생성하는 함수, Base64는 hash 출력의 Base-64 인코딩 버전을 생성하는 함수를 나타내요.
```
Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )
```
saml:sub (string) — 클레임의 주체로, 조직 내 개별 사용자를 고유하게 식별하는 값을 포함해요(예: _cbb88bf52c2510eabe00c1642d4643f41430fe25e3).
saml:sub_type (string) — 이 키는 persistent, transient, 또는 SAML 어서션에 사용된 Subject와 NameID 요소의 전체 Format URI일 수 있어요. 값이 persistent이면 saml:sub의 값이 모든 세션에서 사용자에 대해 동일하다는 뜻이에요. 값이 transient이면 사용자가 각 세션마다 다른 saml:sub 값을 가져요. NameID 요소의 Format 속성에 대한 정보는 인증 응답용 SAML 어서션 구성을 참고하세요.

다음 예시는 앞선 키들을 사용해 Amazon S3의 사용자별 폴더에 권한을 부여하는 권한 정책이에요. 이 정책은 Amazon S3 객체가 saml:namequalifier와 saml:sub를 모두 포함하는 접두사로 식별된다고 가정해요. Condition 요소에 saml:sub_type이 persistent로 설정되어 있는지 확인하는 테스트가 포함되어 있다는 점에 주목하세요. transient로 설정되면 사용자의 saml:sub 값이 각 세션마다 달라질 수 있어, 값을 조합해 사용자별 폴더를 식별하는 데 사용하면 안 돼요.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {
      "StringEquals": {
        "saml:sub_type": "persistent"
      }
    }
  }
}

(중국 리전용 예시)

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {
      "StringEquals": {
        "saml:sub_type": "persistent"
      }
    }
  }
}

IdP의 어서션을 정책 키에 매핑하는 방법은 인증 응답용 SAML 어서션 구성을 참고하세요.

더 알아보기 (Learn more)

IAM에 SAML 아이덴티티 프로바이더 생성 — IAM에 SAML IdP를 만드는 방법을 확인해 보세요.
인증 응답용 SAML 어서션 구성 — SAML 클레임·어서션을 구성하는 방법을 살펴보세요.
SAML 2.0 페더레이션 프린시펄의 AWS Management Console 접근 활성화 — 콘솔 SSO를 구성하는 방법을 참고하세요.