ADFS Study (1). What is ADFS
M365의 Hybrid Azure AD(HAAD)를 어떻게 다뤄볼까를 고민 -> HAAD 의 출발은 조건부 액세스가 아닐까? -> 조건부 액세스를 하려다 보니 로그인 및 인증 개념 필요 -> ADFS와 유사성이 높은 것 같은데 -> ADFS Deep dive 가 Azure AD 및 인증에 도움이 되지 않을까? 로 연쇄작용이 일어나서 ADFS 를 Self Study 방식으로 다뤄보려고 합니다.
아래의 Tech Community 와 Office 365 Conepts 채널의 자료를 참고하였으며, 특히 Youtube 영상은 많은 도움이 되었습니다.
ADFS Deep-Dive: Primer - Microsoft Tech Community
구성 및 감사로그에 대해서는 다른 포스팅에서 이미 다루었기 때문에 이번 Study 포스팅은 제가 궁금했던 것들 위주로 다룰 것입니다.
2021.06.23 - [Office 365] - M365. 테스트 환경 구축(4). ADFS 구성
2017.11.08 - [Exchange] - Exchange Server 2016. AD FS claims-based authentication
2020.09.06 - [Windows Server] - ADFS Events and Logging
[주의사항]
인증이나 AD의 개념에 대해서 자세히 알지 못하기 때문에, 어떠한 개념은 화살표 방향이나 정확성이 떨어질 수 있습니다.
이 글은 제가 Self study를 위해서 작성한 글입니다. 그러다 보면 체계적인 순서가 아닌 의식의 흐름으로 작성될 수 있습니다.
1. What is Active Directory Federation Service
MS 자료에서는 ADFS에 대해서 다음과 같이 설명합니다.
AD FS는 사용자 계정 및 애플리케이션이 완전히 다른 네트워크 또는 조직에 있는 경우에도 클라이언트 컴퓨터(네트워크 내부 또는 외부)에 보호된 인터넷 연결 애플리케이션 또는 서비스에 대한 원활한 SSO 액세스를 제공하는 ID 액세스 솔루션입니다.
애플리케이션이나 서비스가 하나의 네트워크에 있고 사용자 계정이 다른 네트워크에 있는 경우 사용자가 애플리케이션 또는 서비스에 액세스하려고 하면 일반적으로 보조 자격 증명을 묻는 메시지가 표시됩니다. 이러한 보조 자격 증명은 애플리케이션이나 서비스가 있는 영역에서 사용자의 ID를 나타냅니다. 일반적으로 애플리케이션 또는 서비스를 호스트하는 웹 서버에서 가장 적절한 권한 부여 결정을 내리는 데 필요합니다.
AD FS를 사용하면 조직에서 사용자의 디지털 ID를 프로젝션하고 신뢰할 수 있는 파트너에게 액세스 권한을 프로젝션하는 데 사용할 수 있는 신뢰 관계(페더레이션 트러스트)를 제공하여 보조 자격 증명에 대한 요청을 무시할 수 있습니다. 이 페더레이션된 환경에서 각 조직은 고유한 ID를 계속 관리하지만 다른 조직의 ID를 안전하게 적용하고 수용할 수 있습니다.
주요 Active Directory Federation Services 개념 이해 | Microsoft Docs
기술적 관점의 정의에 대해서는 위키에 더 잘 나와 있는 것으로 보입니다.
Active Directory Federation Services - Wikipedia
| Active Directory Federation Services (AD FS), a software component developed by Microsoft, can run on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access-control authorization model to maintain application security and to implement federated identity.[1] Claims-based authentication involves authenticating a user based on a set of claims about that user's identity contained in a trusted token. Such a token is often issued and signed by an entity that is able to authenticate the user by other means, and that is trusted by the entity doing the claims-based authentication.[2] It is part of the Active Directory Services. Microsoft 에서 개발한 소프트웨어 구성 요소 인 AD FS( Active Directory Federation Services )는 Windows Server 운영 체제에서 실행 되어 조직 경계를 넘어 위치하는 시스템 및 응용 프로그램 에 대한 단일 로그온 액세스를 사용자에게 제공할 수 있습니다. 클레임 기반 액세스 제어 권한 부여 모델을 사용 하여 애플리케이션 보안을 유지하고 연합 ID 를 구현 합니다. [1] 클레임 기반 인증은 해당 사용자의 ID 에 대한 클레임 집합을 기반으로 사용자를 인증하는 것을 포함합니다.신뢰할 수 있는 토큰에 포함됩니다. 이러한 토큰은 다른 수단으로 사용자를 인증할 수 있고 클레임 기반 인증을 수행하는 엔터티에서 신뢰하는 엔터티에서 발급 및 서명하는 경우가 많습니다. [2] Active Directory 서비스 의 일부입니다 . |
-> 가장 중요한 표현은 클레임 기반 인증입니다. Claims-based Identity model 이라고도 합니다. 클레임(claim)은 계속 반복적으로 나올 것입니다.
Claims-based identity term definitions | Microsoft Docs
| Claims-based identity A unique identifier that represents a specific user, application, computer, or other entity. It enables that entity to gain access to multiple resources, such as applications and network resources, without entering credentials multiple times. It also enables resources to validate requests from an entity. 특정 사용자, 응용 프로그램, 컴퓨터 또는 기타 엔터티를 나타내는 고유 식별자입니다. 이를 통해 해당 엔터티는 자격 증명을 여러 번 입력하지 않고도 응용 프로그램 및 네트워크 리소스와 같은 여러 리소스에 액세스할 수 있습니다. 또한 리소스에서 엔터티의 요청을 확인할 수 있습니다. |
참고로 entity도 계속 반복되는 단어라서 한번 확인해 보았습니다.
우선 조직 Contoso.kr 과 Adatum.kr이 존재하고, Adatum.kr의 구성원들은 Contoso.kr 의 Application Server에 Access 해야 합니다.
서로의 리소스를 공유할 수 있도록 Trust를 맺어야 Adatum.kr 자격증명으로 Application Server에 Access 할 수 있을 것입니다. (이때 Trust는 AD Trust 이외에 연결하기 위한 방화벽 포트 Open도 의미합니다.)
-> Application Server에 접속하기 위해서 많은 정보와 포트가 Open 되기 때문에 보안적인 측면에서 많은 위험에 노출 될 수 있습니다.
다음과 같이 Contoso.kr Application Server 2만 Federation Trust를 맺어 주면, adatum.kr 구성원들은 Application Server 2에만 액세스 할 수 있도록 설정할 수 있습니다. 이 때 네트워크는 443포트만 열어줍니다.
2. Claims-based Identity Model
Contoso.kr 의 구성원들이 외부에서 제공되는 Application Server가 있습니다.
이 Application Server를 SAP, Salesforce 처럼 구독형 서비스라고 가정합니다.
기존 Kerberos 방식이면 SAP과 Salesforce에 동일한 정보를 기준으로 토큰이 생성 및 전달됩니다.
실제 운영환경에서는 SAP에서는 Email 주소를 기준으로, Salesforce에서는 사번을 기준으로 토큰에 해당 정보가 필요할 수 있습니다.
-> ADFS는 이것을 가능하게 해줍니다.
2. What is claim
ADFS 에서는 Email, employeeNumber 등 각각 속성들을 Claim 이라고 합니다.
Claims-based identity term definitions | Microsoft Docs
| Claim A statement that one subject makes about itself or another subject. For example, the statement can be about a name, identity, key, group, privilege, or capability. Claims are issued by a provider, and they are given one or more values and then packaged in security tokens that are issued by a security token service (STS). They are also defined by a claim value type and, possibly, associated metadata. 한 주체가 자신 또는 다른 주제에 대해 작성하는 진술. 예를 들어, 명령문은 이름, ID, 키, 그룹, 권한 또는 기능에 관한 것일 수 있습니다. 클레임은 공급자에 의해 발급되며 하나 이상의 값이 제공된 다음 STS(보안 토큰 서비스)에서 발급한 보안 토큰으로 패키지됩니다. 또한 클레임 값 유형 및 아마도 연관된 메타데이터에 의해 정의됩니다. |
번역만 보면 헷갈릴 수 있습니다. 저는 "각 속성들이 Claim 일 수 있다" 로 해석하였습니다.
ADFS Management -> Service -> Claim Descriptions 로 이동하면 자세히 확인할 수 있습니다.
제 ADFS 테스트 환경은 Exchange Server 2019, Office 365와의 클레임 인증이 구성되어 있습니다. 우선 Exchange의 Claim Issuance Policy 를 확인해 보면,
UserSID,UPN 관련 규칙을 확인할 수 있습니다.
ADFS와 Application Server가 Federation 구성일 경우에 Claim 인증이 어떻게 진행되는지 예를 통해서 설명 드리겠습니다.
1. 특정 사용자 Pepuri가 SAP에 접속하려고 하려고 하면,
2. SAP은 ADFS 에 접속 및 (확인)요청합니다.
3. 그런 다음 ADFS 서버는 Active Directory에 연결하여 사용자를 인증하고,
4. 사용자가 인증되면 5. ADFS는 SAP에 토큰을 보냅니다.
ADFS에는 애플리케이션 요구 사항에 따라 토큰을 Customize 할 수 있는 기능이 있습니다.
SAP이 Email 속성을 기반으로 토큰이 필요한 경우 ADFS 서버에서 email 속성을 포함한 토큰을 생성하여 SAP에 전달합니다.
ADFS에는 응용 프로그램의 요구 사항에 따라 응답을 사용자 지정할 수 있는 기능이 있습니다.
응용 프로그램의 요구 사항이 사용자가 인증되면, 해당 사용자를 확인하기 위해 토큰에 전자 메일 주소 속성이 필요하므로 ADFS에서 토큰을 생성합니다.
응용 프로그램 공급자는 토큰의 유효성을 검사하고, 사용자에게 액세스 권한을 제공하며 이를 클레임 기반 ID 모델 또는 클레임 기반 액세스 제어 권한 부여 모델이라고 합니다.