Microsoft Entra ID를 사용하여 SAML SSO를 위한 NGINX Plus 구성

보안을 강화하고 사용자 경험을 개선하기 위해 F5 NGINX Plus (R29+)는 이제 SAML(Security Assertion Markup Language)을 지원합니다. SAML은 웹 애플리케이션에 대한 단일 로그인(SSO)을 제공하는 확립된 프로토콜로, 이를 통해 ID 공급자(IdP)는 리소스에 액세스하기 위해 사용자를 인증한 다음 승인을 위해 해당 정보를 서비스 공급자(SP)에게 전달합니다.

이 블로그 게시물에서는 SAML을 기본적으로 지원하지 않는 웹 애플리케이션을 사용하여 NGINX를 Microsoft Entra ID (이전 Azure Active Directory(Azure AD))와 통합하는 방법을 단계별로 다룹니다. 또한 애플리케이션에 SSO를 구현하고 이를 Microsoft Entra ID 생태계와 통합하는 방법도 다룹니다. 튜토리얼을 따라하면 NGINX가 SAML 어설션에서 클레임(UPN, 이름, 성, 그룹 멤버십 포함)을 추출하고 이를 HTTP 헤더를 통해 애플리케이션에 전달하는 방법도 알아볼 수 있습니다.

튜토리얼은 세 단계로 구성되어 있습니다.

1. Microsoft Entra ID를 IdP로 구성
2. SAML 설정 및 NGINX Plus를 역방향 프록시로 구성
3. 구성 테스트

이 튜토리얼을 완료하려면 다음이 필요합니다.

• 30일 무료 체험판으로 받을 수 있는 NGINX Plus(R29+)
• 무료 또는 엔터프라이즈 Microsoft Entra ID 계정
• NGINX Plus 서버에 유효한 SSL/TLS 인증서가 설치되어 있어야 합니다(이 튜토리얼에서는 dev.sports.com.crt 및 dev.sports.com.key를 사용합니다)
• IdP에서 공개 인증서 demonginx.cer 을 다운로드하여 수행할 수 있는 SAML 어설션을 확인하려면

메모 : 이 튜토리얼은 키-값 저장소가 NGINX Plus에만 적용되므로 NGINX 오픈 소스 배포에는 적용되지 않습니다.

NGINX Plus를 SAML 서비스 공급자로 사용

이러한 설정에서 NGINX Plus는 SAML SP 역할을 하며 SAML IdP와 SSO 구현에 참여할 수 있습니다. SAML IdP는 사용자 에이전트를 통해 NGINX Plus와 간접적으로 통신합니다.

아래 다이어그램은 SP 시작 및 요청 및 응답에 대한 POST 바인딩을 통한 SSO 프로세스 흐름을 보여줍니다. 이 커뮤니케이션 채널은 직접적인 것이 아니며 사용자 에이전트를 통해 관리된다는 점을 다시 한 번 기억하는 것이 중요합니다.

그림 1 : AuthnRequest 및 Response에 대한 POST 바인딩이 있는 SAML SP 시작 SSO

1단계: Microsoft Entra ID를 ID 공급자로 구성

Microsoft Entra ID 관리 포털에 액세스하려면 로그인하고 왼쪽 패널로 이동하세요. Microsoft Entra ID를 선택한 다음 SSO 구성이 필요한 디렉토리 제목을 클릭합니다. 선택한 후 엔터프라이즈 애플리케이션을 선택하세요.

그림 2: 관리 포털에서 엔터프라이즈 애플리케이션 선택

신청서를 만들려면 포털 상단에 있는 '새 신청서' 버튼을 클릭하세요. 이 예제에서는 demonginx 라는 애플리케이션을 만들었습니다.

그림 3: Microsoft Entra ID에서 새 애플리케이션 만들기

새로 생성된 애플리케이션 개요 로 리디렉션된 후 왼쪽 메뉴를 통해 시작하기 로 이동하고 관리 아래에서 단일 로그인을 클릭합니다. 그런 다음 SAML을 단일 로그인 방법 으로 선택합니다.

그림 4: SSO 섹션을 사용하여 SAML 구성 시작

엔터프라이즈 애플리케이션에서 SSO를 설정하려면 Microsoft Entra ID 내에서 NGINX Plus를 SP로 등록해야 합니다. 이를 위해 그림 5에서 볼 수 있듯이 Basic SAML Configuration 에서 Edit 옆에 있는 연필 아이콘을 클릭합니다.

다음 값을 추가한 후 저장을 클릭하세요.

• 식별자(엔터티 ID) – https://dev.sports.com
• 답변 URL(Assertion Consumer Service URL) – https://dev.sports.com/saml/acs
• 로그인 URL : https://dev.sports.com
• 로그아웃 URL(선택 사항) : https://dev.sports.com/saml/sls

검증 인증서 사용은 선택 사항입니다. 이 설정을 활성화하면 NGINX에서 두 가지 구성 옵션을 처리해야 합니다.

1. 공개 키로 서명을 확인하려면 $saml_sp_sign_authn을 true 로 설정해야 합니다. 이는 SP에게 IdP로 전송된 AuthnRequest에 서명하도록 지시합니다.
2. $saml_sp_signing_key를 구성하여 이 서명에 사용될 개인 키의 경로를 제공합니다. 서명 확인을 위해 해당 공개 키 인증서를 Microsoft Entra ID에 업로드하세요.

메모 : 이 데모에서는 속성과 클레임이 수정되었고, 새로운 SAML 속성이 추가되었습니다. 이러한 SAML 속성은 IdP에서 전송됩니다. 이러한 속성을 올바르게 수신하고 처리할 수 있도록 NGINX 구성이 설정되어 있는지 확인하세요. NGINX GitHub 저장소 에서 관련 설정을 확인하고 조정할 수 있습니다.

Microsoft Entra ID에서 IdP 인증서(원시)를 다운로드하여 NGINX Plus 인스턴스에 저장합니다.

그림 5: Microsoft Entra ID에서 IdP 인증서(원시) 다운로드

그림 6: 새로운 사용자 또는 그룹 추가

Microsoft Entra ID에서는 사용자 및 그룹을 추가하거나 할당하여 SSO가 활성화된 회사 애플리케이션에 대한 액세스 권한을 부여할 수 있습니다.

왼쪽 메뉴에서 사용자 및 그룹을 클릭한 다음, 상단 버튼인 사용자/그룹 추가를 클릭 합니다.

2단계: SAML 설정 및 NGINX Plus를 역방향 프록시로 구성

NGINX Plus SP에서 파일을 구성하기 전에 필요한 인증서가 있는지 확인하세요.

• TLS 세션 종료를 위한 인증서( dev.sports.com.crt 및 dev.sports.com.key )
• IdP 서명 검증을 위해 Microsoft Entra ID에서 다운로드한 인증서( demonginx.cer )

메모 : 인증서는 SPKI 형식이어야 합니다.

이 단계를 시작하려면 Microsoft Entra ID에서 서명 확인을 위한 IdP 인증서를 다운로드하세요. 그런 다음 PEM을 DER 형식으로 변환합니다.

SAML SP 어설션을 확인하려면 TLS 종료에 사용된 것과 다른 공개/개인 키를 사용하는 것이 좋습니다.

SPKI 형식으로 공개 키 인증서를 추출합니다.

frontend.conf 파일을 편집하여 다음 항목을 업데이트하세요.

• ssl_certificate – TLS 인증서 경로를 포함하도록 업데이트했습니다.
• ssl_certificate_key – TLS 개인 키 경로를 포함하도록 업데이트되었습니다.

실제 배포 시에는 비즈니스 요구 사항에 따라 다양한 백엔드 대상을 사용할 수 있습니다. 이 예에서 백엔드는 사용자 지정 응답을 제공합니다.

사용자의 mail 및 objectid에 대한 새로운 클레임을 추가하여 Microsoft Entra ID의 속성과 클레임을 수정했습니다. 이러한 업데이트를 통해 귀하의 신청서에 보다 개인화되고 맞춤화된 응답을 제공할 수 있어 사용자 경험이 향상됩니다.

그림 7: Microsoft Entra ID의 수정된 속성 및 클레임

다음 단계는 백엔드 애플리케이션으로 트래픽을 프록시할 NGINX를 구성하는 것입니다. 이 데모에서는 백엔드 SAML 애플리케이션이 https://dev.sports.com 에서 공개적으로 사용 가능합니다.

frontend.conf 파일을 편집하세요.

# 이것은 파일 frontend.conf입니다.
# 이것은 SAML SSO로 보호하는 백엔드 애플리케이션입니다.
upstream my_backend { 
zone my_backend 64k; 
server dev.sports.com; 
} 

# REMOTE_USER 필드에 'NameID' 주제를 포함하는 사용자 지정 로그 형식 
log_format saml_sso '$remote_addr - $saml_name_id [$time_local] "$request" "$host" ' 
'$status $body_bytes_sent "$http_referer" ' 
'"$http_user_agent" "$http_x_forwarded_for"'; 

# 프런트엔드 서버 - SAML SSO 인증을 사용한 역방향 프록시 
# 
server { 
# SAML SSO 지원을 구현하는 기능적 위치 
include conf.d/saml_sp.server_conf; 

# 필요에 따라 심각도 수준을 낮춥니다.
error_log /var/log/nginx/error.log debug;
listen 443 ssl;
ssl_certificate /home/ubuntu/dev.sports.com.crt;
ssl_certificate_key /home/ubuntu/dev.sports.com.key;
ssl_session_cache shared:SSL:5m;

location / { 
# 사용자가 인증되지 않은 경우(즉, "saml_access_granted." 
# 변수가 "1"로 설정되지 않은 경우) HTTP 401 Unauthorized 오류가 
# 반환되며, @do_samlsp_flow라는 location에서 처리합니다. 
error_page 401 = @do_samlsp_flow; 

if ($saml_access_granted != "1") { 
return 401;
} 

# 성공적으로 인증된 사용자는 백엔드로 프록시되며, 
# NameID 속성은 HTTP 헤더로 전달됩니다. 
proxy_set_header mail $saml_attrib_mail; # Microsoft Entra ID의 user.mail 
proxy_set_header objectid $saml_attrib_objectid; # Microsoft Entra ID의 objectid 
access_log /var/log/nginx/access.log saml_sso; 
proxy_pass http://my_backend; 
proxy_set_header Host dev.sports.com; 
return 200 "Welcome to Application page\n My objectid is $http_objectid\n My email is $http_mail\n"; 
default_type text/plain; 

} 
} 
# vim: syntax=nginx         

saml_attrib_mail 및 saml_attrib_objectid 속성이 NGINX 구성에 반영되도록 하려면 다음과 같이 saml_sp_configuration.conf 의 키-값 저장소 부분을 업데이트합니다.

키밸_존 존=saml_attrib_mail:1M 상태=/var/lib/nginx/state/saml_attrib_email.json 시간 초과=1시간; 
키밸 $쿠키_인증_토큰 $saml_attrib_mail 존=saml_attrib_mail; 

키밸_존 존=saml_attrib_objectid:1M 상태=/var/lib/nginx/state/saml_attrib_objectid.json 시간 초과=1시간; 
키밸 $쿠키_인증_토큰 $saml_attrib_objectid 존=saml_attrib_objectid; 

다음으로 SAML SSO 구성 파일을 구성합니다. 이 파일에는 SP 및 IdP에 대한 기본 구성이 포함되어 있습니다. 특정 SP 및 IdP 설정에 맞게 사용자 지정하려면 파일에 포함된 여러 개의 map{} 블록을 조정해야 합니다.

이 표는 saml_sp_configuration.conf 내의 변수에 대한 설명을 제공합니다.

아래 코드는 saml_sp_configuration.conf에서 이 사용 사례에 대해서만 편집된 값을 보여줍니다.

메모 : 구성 파일의 나머지 부분이 여전히 파일에 나타나는지 확인하세요(예: 키-값 저장소). 또한 배포에 따라 saml_sp_configuration.conf 파일 내의 변수를 올바르게 조정해야 합니다.

 # SAML SSO 구성 

map $host $saml_sp_entity_id { 
# IdP에 SP를 식별하는 고유 식별자입니다. 
# URL 또는 URN이어야 합니다. 
default "https://dev.sports.com"; 
} 

map $host $saml_sp_acs_url { 
# ACS URL, IdP가 인증 응답으로 리디렉션할 SP의 엔드포인트입니다. 
# "saml_sp.serer_conf" 파일에 정의된 ACS 위치와 일치해야 합니다. 
default "https://dev.sports.com/saml/acs"; 
} 

map $host $saml_sp_request_binding { 
# Single Sign-On(SSO) 프로세스 중에 SP에서 IdP로 인증 요청이 전송되는 방법을 나타냅니다. 
# HTTP-POST 또는 HTTP-Redirect 방법만 허용됩니다. 
default 'HTTP-POST';
} 

map $host $saml_sp_sign_authn { 
# SP가 IdP로 전송된 AuthnRequest에 서명해야 하는지 여부. 
default "false"; 
} 

map $host $saml_sp_decryption_key { 
# SP가 암호화된 어설션을 해독하는 데 사용하는 개인 키 
# 또는 IdP의 NameID를 지정합니다. 
default ""; 
} 

map $host $saml_sp_force_authn { 
# SP가 IdP에서 사용자 재인증을 강제해야 하는지 여부. 
default "false"; 
} 

map $host $saml_sp_nameid_format { 
# IdP에서 생성된 SAML 어설션의 이름 식별자에 대한 원하는 형식을 나타냅니다. SAML 2.0 핵심 사양의 섹션 8.3을 확인하세요. 
# (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) 
# 허용되는 NameID 형식 목록은 
default "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"; 
} 

map $host $saml_sp_relay_state { 
# SP가 성공적으로 로그인한 후 리디렉션해야 하는 상대 또는 절대 URL입니다. 
default ""; 
} 

map $host $saml_sp_want_signed_response { 
# SP가 IdP의 SAML 응답을 
# 디지털 서명할지 여부입니다. 
default "false"; 
} 

map $host $saml_sp_want_signed_assertion { 
# SP가 IdP의 SAML 어설션을 
# 디지털 서명할 것인지 여부. 
default "true"; 
} 

map $host $saml_sp_want_encrypted_assertion { 
# SP가 IdP의 SAML 어설션을 
# 암호화할 것인지 여부. 
default "false"; 
} 

map $host $saml_idp_entity_id { 
# IdP를 SP에 식별하는 고유 식별자. 
# URL 또는 URN이어야 합니다. 
default "https://sts.windows.net/8807dced-9637-4205-a520-423077750c60/";
} 

map $host $saml_idp_sso_url { 
# SP가 SAML AuthnRequest를 보내어 
# 인증 프로세스를 시작할 IdP 엔드포인트입니다. 
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_idp_verification_certificate { 
# IdP에서 수신한 SAML Response, LogoutRequest 또는 LogoutResponse에서 디지털 서명을 확인하는 데 사용되는 인증서 파일입니다. 
# PKCS#1 형식의 공개 키여야 합니다. # X.509 PEM을 DER 형식으로 변환하는 방법에 대한 설명서를 참조하세요. 
default "/etc/nginx/conf.d/demonginx.spki"; 
} 

######### 단일 로그아웃(SLO) ######### 

map $host $saml_sp_slo_url { 
# IdP가 SAML LogoutRequest를 보내서 
# 로그아웃 프로세스를 시작하거나 LogoutResponse를 보내서 로그아웃을 확인하는 SP 엔드포인트입니다. 
default "https://dev.sports.com/saml/sls"; 
} 

map $host $saml_sp_slo_binding { 
# 단일 로그아웃(SLO) 프로세스 중에 SP에서 IdP로 LogoutRequest 또는 LogoutResponse를 보내는 방법을 말합니다. 
# HTTP-POST 또는 HTTP-Redirect 메서드만 허용됩니다. 
default 'HTTP-POST';
} 

map $host $saml_sp_sign_slo { 
# SP가 LogoutRequest 또는 LogoutResponse에 서명해야 하는지 여부 
# IdP로 전송됨. 
default "false"; 
} 

map $host $saml_idp_slo_url { 
# SP가 LogoutRequest를 보내 로그아웃 프로세스를 시작하거나 LogoutResponse를 보내 로그아웃을 확인하는 IdP 엔드포인트. 
# 설정하지 않으면 SAML 단일 로그아웃(SLO) 기능이 비활성화되고 
# '로그아웃' 위치에 대한 요청은 
# 사용자 세션이 종료되고 로그아웃 랜딩 페이지로 리디렉션됩니다. 
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2";
} 

map $host $saml_sp_want_signed_slo { 
# SP가 IdP의 SAML LogoutRequest 또는 LogoutResponse를 원하는지 여부 
# 디지털 서명. 
default "true"; 
} 

map $host $saml_logout_landing_page { 
# /logout 요청 후 사용자를 리디렉션할 위치. 이것은 
# 사용자 정의 로그아웃 페이지 또는 전체 URL로 대체될 수 있습니다. 
default "/_logout"; # 기본 제공, 간단한 로그아웃 페이지 
} 

map $proto $saml_cookie_flags { 
http "Path=/; SameSite=lax;"; # HTTP/일반 텍스트 테스트용 
https "Path=/; SameSite=lax; HttpOnly; Secure;"; # 프로덕션 권장 사항 
} 

map $http_x_forwarded_port $redirect_base { 
"" $proto://$host:$server_port; 
default $proto://$host:$http_x_forwarded_port; 
} 

map $http_x_forwarded_proto $proto { 
"" $scheme; 
default $http_x_forwarded_proto;
} 
# 이 줄 아래에 고급 구성 
# saml_sp.server_conf의 추가 고급 구성(서버 컨텍스트) 

######### SAML 관련 키-값 데이터베이스를 보관하는 공유 메모리 영역 

# AuthnRequest 및 LogoutRequest 메시지 식별자(ID)를 저장하는 영역 
# 재생 공격을 방지하기 위한 것입니다. (필수) 
# Timeout은 SP가 IDP로부터 응답을 기다리는 시간을 결정합니다. 
# 즉, 사용자 인증 프로세스에 걸리는 시간입니다. 
keyval_zone zone=saml_request_id:1M state=/var/lib/nginx/state/saml_request_id.json timeout=5m; 

# 재생 공격을 방지하기 위해 SAML 응답 메시지 식별자(ID)를 저장하는 영역입니다. (필수) 
# Timeout은 SP가 재사용을 방지하기 위해 ID를 보관하는 기간을 결정합니다. 
keyval_zone zone=saml_response_id:1M state=/var/lib/nginx/state/saml_response_id.json timeout=1h; 

# SAML 세션 액세스 정보를 저장하는 영역. (필수) 
# 타임아웃은 SP가 세션 액세스 결정(세션 수명)을 유지하는 기간을 결정합니다. 
keyval_zone zone=saml_session_access:1M state=/var/lib/nginx/state/saml_session_access.json timeout=1h; 

# SAML NameID 값을 저장하는 영역. (필수) 
# Timeout은 SP가 NameID 값을 보관하는 기간을 결정합니다. 세션 수명과 동일해야 합니다. 
keyval_zone zone=saml_name_id:1M state=/var/lib/nginx/state/saml_name_id.json timeout=1h; 

# SAML NameID 형식 값을 저장하는 영역. (필수) 
# Timeout은 SP가 NameID 형식 값을 보관하는 기간을 결정합니다. 세션 수명과 동일해야 합니다. 
keyval_zone zone=saml_name_id_format:1M state=/var/lib/nginx/state/saml_name_id_format.json timeout=1h; 

# SAML SessionIndex 값을 저장하는 영역입니다. (필수) 
# Timeout은 SP가 SessionIndex 값을 얼마나 오래 보관할지 결정합니다. 세션 수명과 동일해야 합니다. 
keyval_zone zone=saml_session_index:1M state=/var/lib/nginx/state/saml_session_index.json timeout=1h; 

# SAML AuthnContextClassRef 값을 저장하는 영역. (필수) 
# Timeout은 SP가 AuthnContextClassRef 값을 보관하는 기간을 결정합니다. 세션 수명과 동일해야 합니다. 
keyval_zone zone=saml_authn_context_class_ref:1M state=/var/lib/nginx/state/saml_authn_context_class_ref.json timeout=1h; 

# SAML 속성 값을 저장하는 영역. (선택 사항)
# Timeout은 SP가 속성 값을 보관하는 기간을 결정합니다. 세션 수명과 동일해야 합니다. 
keyval_zone zone=saml_attrib_uid:1M state=/var/lib/nginx/state/saml_attrib_uid.json timeout=1h; 
keyval_zone zone=saml_attrib_name:1M state=/var/lib/nginx/state/saml_attrib_name.json timeout=1h; 
keyval_zone zone=saml_attrib_memberOf:1M state=/var/lib/nginx/state/saml_attrib_memberOf.json timeout=1h; 

######### 키-값 데이터베이스에서 키(세션 쿠키)로 값을 조회하는 SAML 관련 변수입니다. 

# 필수: 
keyval $saml_request_id $saml_request_redeemed zone=saml_request_id; # SAML 요청 ID 
keyval $saml_response_id $saml_response_redeemed zone=saml_response_id; # SAML 응답 ID 
keyval $cookie_auth_token $saml_access_granted zone=saml_session_access; # SAML 액세스 결정 
keyval $cookie_auth_token $saml_name_id zone=saml_name_id; # SAML 이름 ID 
keyval $cookie_auth_token $saml_name_id_format zone=saml_name_id_format; # SAML 이름 ID 형식 
keyval $cookie_auth_token $saml_session_index zone=saml_session_index; # SAML 세션 인덱스 
keyval $cookie_auth_token $saml_authn_context_class_ref zone=saml_authn_context_class_ref; # SAML AuthnContextClassRef 

# 선택 사항: 
키값 $쿠키_인증_토큰 $saml_attrib_uid 영역=saml_attrib_uid; 
키값 $쿠키_인증_토큰 $saml_attrib_name 영역=saml_attrib_name; 
키값 $쿠키_인증_토큰 $saml_attrib_memberOf 영역=saml_attrib_memberOf; 

키값_영역 영역=saml_attrib_mail:1M 상태=/var/lib/nginx/state/saml_attrib_mail.json 시간 초과=1h; 
키값 $쿠키_인증_토큰 $saml_attrib_mail 영역=saml_attrib_mail; 

키값 $쿠키_인증_토큰 $saml_attrib_objectid 영역=saml_attrib_objectid; 
keyval_zone zone=saml_attrib_objectid:1M state=/var/lib/nginx/state/saml_attrib_objectid.json timeout=1h; 

######### SAML SSO 및 SLO 기능을 구현하는 모듈을 가져옵니다. 
js_import samlsp from conf.d/saml_sp.js; 

3단계: 구성 테스트

구성을 테스트하려면 두 가지 부분이 필요합니다.

1. SAML 흐름 확인
2. SP 시작 로그아웃 기능 테스트

SAML 흐름 확인

NGINX Plus를 사용하여 SAML SP를 구성하고 Microsoft Entra ID를 사용하여 IdP를 구성한 후에는 SAML 흐름을 검증하는 것이 중요합니다. 이 검증 프로세스는 IdP를 통한 사용자 인증이 성공적이고 SP로 보호되는 리소스에 대한 액세스가 허용되었는지 확인합니다.

SP에서 시작한 SAML 흐름을 확인하려면 원하는 브라우저를 열고 주소 표시줄에 https://dev.sports.com을 입력하세요. IdP 로그인 페이지로 이동합니다.

그림 8: IdP 로그인 페이지

IdP의 로그인 페이지에 구성된 사용자의 자격 증명을 입력하세요. IdP는 제출 시 사용자를 인증합니다.

그림 9: 구성된 사용자의 자격 증명 입력

세션을 성공적으로 설정하면 사용자는 이전에 요청한 보호 리소스에 대한 액세스 권한을 부여받습니다. 그 후, 해당 리소스가 사용자의 브라우저에 표시됩니다.

그림 10: 성공적으로 로드된 애플리케이션 페이지

SP 및 IdP 로그를 확인하면 SAML 흐름에 대한 귀중한 정보를 얻을 수 있습니다. SP 측(NGINX Plus)에서는 auth_token 쿠키가 올바르게 설정되었는지 확인하세요. IdP 측(Microsoft Entra ID)에서는 인증 프로세스가 오류 없이 완료되고 SAML 어설션이 SP로 전송되었는지 확인합니다.

NGINX access.log 는 다음과 같아야 합니다.

127.0.0.1 - - [2023년 8월 14일:21:25:49 +0000] "GET / HTTP/1.0" 200 127 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15" "-" 

99.187.244.63 - Akash Ananthanarayanan [2023년 8월 14일:21:25:49 +0000] "GET / HTTP/1.1" "dev.sports.com" 200 127 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15(KHTML, like Gecko) 버전/16.1 Safari/605.1.15" "- 

NGINX debug.log 는 다음과 같습니다.

2023/08/14 21:25:49 [정보] 27513#27513: *399 js: SAML SP 성공, 세션 생성 _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d 

SP 시작 로그아웃 기능 테스트

SAML 단일 로그아웃(SLO)을 사용하면 사용자는 한 번의 작업으로 관련 모든 IdP 및 SP에서 로그아웃할 수 있습니다. NGINX Plus는 SP 시작 로그아웃 시나리오와 IdP 시작 로그아웃 시나리오를 지원하여 SSO 환경에서 보안과 사용자 경험을 향상시킵니다. 이 예에서는 SP가 시작한 로그아웃 시나리오를 사용합니다.

그림 11: LogoutRequest 및 LogoutResponse에 대한 POST/리디렉션 바인딩이 있는 SAML SP 시작 SLO

세션을 인증한 후 SP에 구성된 로그아웃 URL로 접속하여 로그아웃하세요. 예를 들어, NGINX Plus에서 https://dev.sports.com/logout을 로그아웃 URL로 설정한 경우, 해당 URL을 브라우저의 주소창에 입력하세요.

그림 12: 세션에서 성공적으로 로그아웃

안전한 로그아웃을 보장하기 위해 SP는 SAML 요청을 시작해야 하며, 이후 IdP에서 이 요청을 검증하고 처리해야 합니다. 이 작업은 사용자 세션을 효과적으로 종료하고 IdP는 SAML 응답을 보내 사용자 브라우저를 SP로 다시 리디렉션합니다.

결론

축하해요! 이제 NGINX Plus는 SAML SP 역할을 하여 인증 프로세스에 보안과 편의성을 한 단계 더 높여줍니다. 이 새로운 기능은 NGINX Plus에 있어 큰 진전으로, 보안과 효율성을 우선시하는 조직에 더욱 강력하고 다재다능한 솔루션을 제공할 수 있습니다. 

NGINX Plus에서 SAML 사용에 대해 자세히 알아보기

NGINX Plus 의 30일 무료 평가판을 시작하여 오늘부터 NGINX Plus 에서 SAML 사용을 시작할 수 있습니다. 이 글이 유익하다고 생각되길 바라며, 귀하의 피드백을 환영합니다.

SAML을 갖춘 NGINX Plus에 대한 자세한 내용은 아래 리소스에서 확인할 수 있습니다.

• NGINX Plus R29 발표
• GitHub에서 참조 구현으로서 NGINX Plus의 SAML 지원