모든 사용자를 AWS 내에서 관리하지 않기 위해 ID Federation 사용 즉, 때로는 사용자를 위한 외부 소스가 필요하고 그 소스를 통해 AWS 리소스에 액세스할 수 있게 해야 함
페더레이션은 AWS 밖 사용자가 AWS 리소스에 액세스하는 임시 역할을 수행하게 되므로 해당 사용자는 ID가 제공된 액세스 역할을 수행
AWS에서 페더레이션을 하는 여러가지 방법
SAML 2.0
Custom Identity Broker (사용자 지정 자격 브로커)
Web Identity Federation with Amazon Cognito (Cognito를 통한 웹 ID 페더레이션)
Web Identity Federation without Amazon Cognito (Cognito를 통하지 않는 웹 ID 페더레이션)
Single Sign On (SSO)
Non-SAML with AWS Microsoft AD (AWS Microsoft AD를 통한 비 SAML)
사용자 페더레이션을 사용하면 사용자 관리가 AWS 밖에서 이루어지므로 IAM 사용자를 만들 필요가 없으며 사용자와 사용자를 위한 타사 소스가 있으므로 사용자를 관리하는데 있어 AWS는 타사 소스를 신뢰해야 함 이 방식으로 사용자들이 타사 소스로 로그인해 보안 인증을 받고 AWS에 액세스할 수 있게 됨
SAML 2.0 Federation
가장 흔한 페더레이션 방법
SAML 2.0는 Active Directory, ADFS를 통합할 수 있으며 SAML 2.0 사양과 호환되는 다른 디렉토리도 존재
SAML 2.0 페더레이션으로 임시 보안 인증을 이용해 AWS 콘솔이나 CLI에 액세스할 수 있음
직원별로 IAM 사용자를 만들 필요 없음
Active Directory는 사용자를 온프레미스하는 매우 일반적인 방법이며 이곳에 사용자를 생성하면 SAML 2.0 페더레이션 덕에 AWS에 액세스할 수 있음 조직 내에서 인증을 받은 후 SAML 2.0 Assertion을 AWS 내 자격 증명과 교환한 후 STS가 리소스나 콘솔에 액세스할 수 있게 함
예1 : 프로그램에 따라서 AWS 리소스에 액세스) 사용자 관리는 조직 온프레미스 내에 바깥에서 수행될 때, 클라이언트 애플리케이션이 AWS 내 S3 버킷에 액세스할 때 이 경우 클라이언트 앱은 먼저 자격 증명 제공자에게 인증을 요청하고 자격 증명 제공자는 LDAP를 확인하거나 ID 저장소 같은 곳을 확인해 올바르게 인증되었는지를 살핌 그 후 SAML Assertion을 반환하며 클라이언트는 Assertion을 AWS 자격 증명과 교환하기 위해 SAML STL API에서 AssumeRole을 호출하고 STS는 SAML Assertion을 검토하여 신뢰성을 제대로 준수하는지 확인한 후 임시 보안 자격 증명을 발급하여 주어 액세스하려던 S3 버킷에 액세스할 수 있게 됨
예2 : 콘솔에 액세스) AWS 콘솔에 액세스하려고 할 때 브라우저가 LDAP와 자격 증명 제공자를 통해 인증을 하면 SAML 2.0 Assertion이 반환되고 Assertion을 AWS의 로그인 URL에 자동으로 보내면 STS가 이를 확인하고 임시 자격 증명을 반환하고 클라이언트는 AWS 관리 콘솔로 리다이렉트되게 되어 AWS를 정상 이용할 수 있음
SAML 2.0 Federation – Active Directory FS
ADFS가 SAML 2.0과 호환될 때 AWS에 액세스 브라우저 인터페이스가 ADFS로 로그인하면 ADFS는 사용자가 제대로 인증됐는지 아이덴티티 스토어를 통해 확인한 후 ADFS는 SAML 응답을 반환하고 STS가 이를 확인해 역할과 교환하며 임시 자격 증명을 반환하고 임시 자격 증명으로 관리 콘솔이나 AWS 내 리소스에 액세스할 수 있게 됨
SAML 2.0 Federation
신뢰하기 위해 IAM과 SAML 간에 신뢰를 구축해야 함
SAML은 웹 기반의 교차 도메인 SSO를 활성화
AssumeRoleWithSAML API를 사용
SAML 페더레이션은 오래된 방식이며 이에 대한 새로운 서비스인 Amazon Single Sign On(SSO)가 존재
Custom Identity Broker Application
만약 현재의 온프레미스 저장소가 SAML 2.0과 호환되지 않을 경우 사용자 지정 자격 증명 보로커 애플리케이션 작성이 필요
작성할 자격 증명 브로커는 사용자들을 위한 적절한 IAM 정책을 결정해야 함 이 경우 AssumeRole 혹은 GetFederationToken API를 이용
사용자가 자격 증명 브로커를 이용해 인증을 하면 자격 증명 브로커는 그 사용자가 제대로 인증됐는지 검증한 후 자격 증명 브로커는 STS에게 특정 액센열 위한 자격 증명을 요청하고 이후 사용자 지정 자격 증명 브로커는 이 자격 증명을 우리에게 반환하여 콘솔과 AWS API 등에 액세스할 수 있게 함 즉, 자격 증명 브로커 자체가 STS와 소통하여 자격 증명을 반환하므로 자격 증명 브로커에게 많은 권한이 존재
Web Identity Federation – AssumeRoleWithWebIdentity
위의 경우 회사 내 사용자들이 온프레미스로 ID Federation을 통해 AWS에 액세스했지만 만약 애플리케이션 사용자들이 AWS에 액세스하게 하기 위해서는 Web ID Federation을 이용해야 함
이는 권장되는 방법은 아니며 대신 익명 사용자의 액세스와 데이터 동기화 및 다요소 인증을 지원하는 Cognito를 권장
예) STS API AssumeRoleWithIdentity로 구현한 웹 ID Federation 모바일 클라이언트 앱(Facebook, Google, Amazon.com)이 로그인한 후 자격 증명인 토큰을 받게 되며 이 토큰을 AssumeRoleWithIdentity를 이용해 STS와 교환하게 되고 STS는 로그인을 신뢰하기 때문에 AWS 자격 증명을 반환 이제 모바일 클라이언트는 AWS 자격 증명으로 여러 IAM 정책과 다중 테이블에 액세스 가능 GameScores는 3단계 프로세스이며 먼저 자격 증명 제공자로 로그인하고 STS와 이를 교환하고 AWS에 액세스하게 됨
AWS Cognito
클라이언트 측(모바일 혹은 웹 애플리케이션)에서 AWS 리소스에 대한 직접 액세스를 제공하기 위해 사용
예) Facebook으로 로그인하여 S3 버킷에 쓰기 작업을 할 수 있는 임시 액세스를 주고 싶을 때 클라이언트가 S3 버킷에 직접 액세스하는게 훨씬 효율적
하지만 계정 내 애플리케이션을 위해 IAM 사용자를 생성할 수 없음 예) 사용자가 몇 백만 명일 때, 각 사용자를 위해 IAM 사용자를 다 만들 수 없음 그러므로 이를 위해 ID Federation을 사용
또는 자격 증명 제공자 또는 익명으로 로그인해서 Cognito API로 AWS 자격 증명을 받은 후, 자격 증명에 IAM 역할이 첨부되어 있어 S3 버킷에 액세스할 수 있게 됨 예) 애플리케이션이 자격 증명 제공자로 사용자 이름과 암호를 넣어 로그인하게 되면 토큰을 받게 되고 토큰을 Cognito Federation 자격 증명(FIP)과 교환하여 토큰을 검증한 후 백엔드의 STS로부터 자격 증명을 얻게 됨 그 후 임시 AWS 자격 증명을 발급하게 되며 이 역할에 첨부해둔 정책 덕분에 S3 버킷에 액세스할 때 사용하게 됨 즉, Web ID Federation의 중심에 Cognito가 존재
