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

보안을 강화하고 사용자 경험을 개선하기 위해 NGINX Plus(R29+)는 이제 SAML(Security Assertion Markup Language)을 지원합니다. 웹 애플리케이션에 Single Sign-On(SSO)을 제공하는 확립된 프로토콜인 SAML은 ID provider(IdP)가 리소스에 대한 액세스를 위해 사용자를 인증한 다음 해당 정보를 service provider(SP)에 전달하여 권한을 부여받을 수 있도록 합니다.

이 포스트에서는 기본적으로 SAML을 지원하지 않는 웹 애플리케이션을 사용하여 이전에 Azure AD(Azure Active Directory)로 알려진 Microsoft Entra ID와 NGINX를 통합하는 방법을 단계별로 다룹니다. 또한 애플리케이션에 SSO를 구현하고 이를 Microsoft Entra ID 에코시스템과 통합하는 방법도 다룹니다. 튜토리얼을 따라가다 보면 NGINX가 SAML 어설션에서 클레임(사용자 이름, 이름, 성, 그룹 멤버십 포함)을 추출한 다음 HTTP 헤더를 통해 애플리케이션에 전달하는 방법도 추가로 배우게 됩니다.

이 튜토리얼에는 세 단계가 포함되어 있습니다:

Microsoft Entra ID를 IdP로 구성하기
SAML 설정 및 리버스 프록시로 NGINX Plus 구성하기
구성 테스트하기

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

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

참고: 이 튜토리얼은 key-value 저장소가 NGINX Plus 전용이므로 NGINX 오픈 소스 배포에는 적용되지 않습니다.

목차
1. NGINX Plus를 SAML Service Provider로 사용
2. 1단계: Microsoft Entra ID를 Identity Provide로 구성하기
3. 2단계: SAML 설정 및 NGINX Plus를 리버스 프록시로 구성하기
4. 3단계: 구성 테스트
4-1. SAML 흐름 확인
4-2. SP initiated Logout 기능 테스트
5. 결론
6. NGINX Plus에서 SAML 사용에 대해 자세히 알아보기

1. NGINX Plus를 SAML Service Provider로 사용

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

아래 다이어그램은 요청 및 응답을 위한 SP 개시 및 POST 바인딩이 있는 SSO 프로세스 흐름을 보여줍니다. 이 통신 채널은 직접적인 것이 아니며 사용자 에이전트를 통해 관리된다는 점에 다시 한번 유의해야 합니다.

그림 1: AuthnRequest 및 응답에 대한 POST 바인딩이 포함된 SAML SP 시작 SSO

2. 1단계: Microsoft Entra ID를 Identity Provide로 구성하기

Microsoft Entra ID 관리 포털에 액세스하려면 로그인하고 왼쪽 패널로 이동합니다. Microsoft Entra ID를 선택한 다음 SSO 구성이 필요한 디렉토리의 제목을 클릭합니다. 선택한 후 Enterprise applications을 선택합니다.

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

애플리케이션을 만들려면 포털 상단의 New application 버튼을 클릭합니다. 이 예제에서는 demonginx라는 애플리케이션을 만들었습니다.

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

새로 만든 애플리케이션 Overview로 리다이렉션 된 후 왼쪽 메뉴에서 Getting Started로 이동하여 Manage에서 Single sign-on을 클릭합니다. 그런 다음 single sign-on method로 SAML을 선택합니다.

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

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

다음 값을 추가한 후 Save를 클릭합니다:

Identifier (Entity ID) – https://dev.sports.com
회신 URL (Assertion Consumer Service URL) – https://dev.sports.com/saml/acs
Sign on URL: https://dev.sports.com
Logout URL (Optional): https://dev.sports.com/saml/sls

확인 인증서 사용은 선택 사항입니다. 이 설정을 사용하도록 설정할 때는 NGINX에서 두 가지 구성 옵션을 처리해야 합니다:

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

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

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

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

그림 5: Microsoft Entra ID에서 IdP Certificate(Raw) 다운로드하기

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

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

왼쪽 메뉴에서 User and groups를 클릭한 다음 상단 버튼 Add user/group 을 클릭합니다.

3. 2단계: SAML 설정 및 NGINX Plus를 리버스 프록시로 구성하기

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

Terminating TLS session을 위한 인증서(dev.sports.com.crt 및 dev.sports.com.key)
IdP 서명 확인을 위해 Microsoft Entra ID에서 다운로드한 인증서(demonginx.cer)

참고: 인증서는 SPKI 형식이어야 합니다.

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

openssl x509 -in demonginx.cer -outform DER -out demonginx.der

SAML SP 어설션을 확인하려는 경우, TLS Termination에 사용된 것과 다른 public/private key를 사용하는 것이 좋습니다.

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

openssl x509 -inform DER -in demonginx.der -pubkey -noout > demonginx.spki

frontend.conf 파일을 편집하여 이러한 항목을 업데이트합니다:

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

프로덕션 배포에서는 비즈니스 요구 사항에 따라 다른 백엔드 대상을 사용할 수 있습니다. 이 예에서는 백엔드에서 사용자 지정 응답을 제공합니다:

“Welcome to Application page\n My objectid is $http_objectid\n My email is $http_mail\n”;

사용자의 메일 및 objectid에 대한 새로운 클레임을 추가하여 Microsoft Entra ID의 속성 및 클레임을 수정했습니다. 이러한 업데이트를 통해 애플리케이션에 보다 개인화된 맞춤형 응답을 제공할 수 있으므로 사용자 환경이 개선됩니다.

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

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

frontend.conf 파일을 편집합니다:

# This is file frontend.conf
# This is the backend application we are protecting with SAML SSO
upstream my_backend {
zone my_backend 64k;
server dev.sports.com;
}

# Custom log format to include the ‘NameID’ subject in the REMOTE_USER field
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”‘;

# The frontend server – reverse proxy with SAML SSO authentication
#
server {
# Functional locations implementing SAML SSO support
include conf.d/saml_sp.server_conf;

# Reduce severity level as required
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 / {
# When a user is not authenticated (i.e., the “saml_access_granted.”
# variable is not set to “1”), an HTTP 401 Unauthorized error is
# returned, which is handled by the @do_samlsp_flow named location.
error_page 401 = @do_samlsp_flow;

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

# Successfully authenticated users are proxied to the backend,
# with the NameID attribute passed as an HTTP header
proxy_set_header mail $saml_attrib_mail; # Microsoft Entra ID’s user.mail
proxy_set_header objectid $saml_attrib_objectid; # Microsoft Entra ID’s 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의 key-value 저장소(Store) 부분을 업데이트합니다:

keyval_zone    zone=saml_attrib_mail:1M                state=/var/lib/nginx/state/saml_attrib_email.json   timeout=1h; 
keyval   $cookie_auth_token $saml_attrib_mail    zone=saml_attrib_mail; 

 keyval_zone zone=saml_attrib_objectid:1M            state=/var/lib/nginx/state/saml_attrib_objectid.json   timeout=1h; 
keyval   $cookie_auth_token $saml_attrib_objectid   zone=saml_attrib_objectid;

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

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

Variable	Description
`saml_sp_entity_id`	사용자가 애플리케이션에 액세스하는 데 사용하는 URL입니다.
`saml_sp_acs_url`	서비스 제공업체가 SAML 응답을 수신 및 처리하고, 사용자의 신원을 추출한 다음, 제공된 정보를 기반으로 요청된 리소스에 대한 액세스를 허용하거나 거부하는 데 사용하는 URL입니다.
`saml_sp_sign_authn`	SP에서 IdP로의 SAML 요청을 서명할지 여부를 지정합니다. 서명은 SP 서명 키를 사용하여 수행되며, 서명을 확인하려면 연결된 인증서를 IdP에 업로드해야 합니다.
`saml_sp_signing_key`	SP에서 IdP로 SAML 요청을 서명하는 데 사용되는 서명 키입니다. 서명을 확인하려면 연결된 인증서를 IdP에 업로드해야 합니다.
`saml_idp_entity_id`	IdP를 정의하는 데 사용되는 ID입니다.
`saml_idp_sso_url`	SP가 인증 요청을 시작하기 위해 SAML 어설션 요청을 보내는 IdP 엔드포인트입니다.
`saml_idp_verification_certificate`	IdP에서 받은 서명된 SAML 어설션을 확인하는 데 사용되는 인증입니다. 인증서는 IdP에서 제공하며 SPKI 형식이어야 합니다.
`saml_sp_slo_url`	IdP가 (로그아웃 프로세스를 시작할 때) SAML 로그아웃 요청을 보내는 SP 엔드포인트 또는 (로그아웃을 확인할 때) 로그아웃 응답을 보내는 SP 엔드포인트입니다.
`saml_sp_sign_slo`	로그아웃 SAML에 SP가 서명할지 여부를 지정합니다.
`saml_idp_slo_url`	SP가 로그아웃 프로세스를 시작할 때 로그아웃 요청을 보내거나 로그아웃을 확인할 때 로그아웃 응답을 보내는 IdP 엔드포인트입니다.
`saml_sp_want_signed_slo`	SAML SP가 IdP의 SAML 로그아웃 응답 또는 요청에 서명할지 여부를 지정합니다.

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

참고: 구성 파일의 나머지 부분(예: Key-Value Store)이 여전히 파일에 표시되는지 확인하세요. 또한 배포에 따라 saml_sp_configuration.conf 파일 내의 변수를 적절하게 조정했는지 확인하세요.

# SAML SSO configuration

map $host $saml_sp_entity_id {
# Unique identifier that identifies the SP to the IdP.
# Must be URL or URN.
default “https://dev.sports.com”;
}

map $host $saml_sp_acs_url {
# The ACS URL, an endpoint on the SP where the IdP
# will redirect to with its authentication response.
# Must match the ACS location defined in the “saml_sp.serer_conf” file.
default “https://dev.sports.com/saml/acs”;
}

map $host $saml_sp_request_binding {
# Refers to the method by which an authentication request is sent from
# the SP to an IdP during the Single Sign-On (SSO) process.
# Only HTTP-POST or HTTP-Redirect methods are allowed.
default ‘HTTP-POST’;
}

map $host $saml_sp_sign_authn {
# Whether the SP should sign the AuthnRequest sent to the IdP.
default “false”;
}

map $host $saml_sp_decryption_key {
# Specifies the private key that the SP uses to decrypt encrypted assertion
# or NameID from the IdP.
default “”;
}

map $host $saml_sp_force_authn {
# Whether the SP should force re-authentication of the user by the IdP.
default “false”;
}

map $host $saml_sp_nameid_format {
# Indicates the desired format of the name identifier in the SAML assertion
# generated by the IdP. Check section 8.3 of the SAML 2.0 Core specification
# (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)
# for the list of allowed NameID Formats.
default “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”;
}

map $host $saml_sp_relay_state {
# Relative or absolute URL the SP should redirect to
# after successful sign on.
default “”;
}

map $host $saml_sp_want_signed_response {
# Whether the SP wants the SAML Response from the IdP
# to be digitally signed.
default “false”;
}

map $host $saml_sp_want_signed_assertion {
# Whether the SP wants the SAML Assertion from the IdP
# to be digitally signed.
default “true”;
}

map $host $saml_sp_want_encrypted_assertion {
# Whether the SP wants the SAML Assertion from the IdP
# to be encrypted.
default “false”;
}

map $host $saml_idp_entity_id {
# Unique identifier that identifies the IdP to the SP.
# Must be URL or URN.
default “https://sts.windows.net/8807dced-9637-4205-a520-423077750c60/”;
}

map $host $saml_idp_sso_url {
# IdP endpoint that the SP will send the SAML AuthnRequest to initiate
# an authentication process.
default “https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2”;
}

map $host $saml_idp_verification_certificate {
# Certificate file that will be used to verify the digital signature
# on the SAML Response, LogoutRequest or LogoutResponse received from IdP.
# Must be public key in PKCS#1 format. See documentation on how to convert
# X.509 PEM to DER format.
default “/etc/nginx/conf.d/demonginx.spki”;
}

######### Single Logout (SLO) #########

map $host $saml_sp_slo_url {
# SP endpoint that the IdP will send the SAML LogoutRequest to initiate
# a logout process or LogoutResponse to confirm the logout.
default “https://dev.sports.com/saml/sls”;
}

map $host $saml_sp_slo_binding {
# Refers to the method by which a LogoutRequest or LogoutResponse
# is sent from the SP to an IdP during the Single Logout (SLO) process.
# Only HTTP-POST or HTTP-Redirect methods are allowed.
default ‘HTTP-POST’;
}

map $host $saml_sp_sign_slo {
# Whether the SP must sign the LogoutRequest or LogoutResponse
# sent to the IdP.
default “false”;
}

map $host $saml_idp_slo_url {
# IdP endpoint that the SP will send the LogoutRequest to initiate
# a logout process or LogoutResponse to confirm the logout.
# If not set, the SAML Single Logout (SLO) feature is DISABLED and
# requests to the ‘logout’ location will result in the termination
# of the user session and a redirect to the logout landing page.
default “https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2”;
}

map $host $saml_sp_want_signed_slo {
# Whether the SP wants the SAML LogoutRequest or LogoutResponse from the IdP
# to be digitally signed.
default “true”;
}

map $host $saml_logout_landing_page {
# Where to redirect user after requesting /logout location. This can be
# replaced with a custom logout page, or complete URL.
default “/_logout”; # Built-in, simple logout page
}

map $proto $saml_cookie_flags {
http “Path=/; SameSite=lax;”; # For HTTP/plaintext testing
https “Path=/; SameSite=lax; HttpOnly; Secure;”; # Production recommendation
}

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;
}
# ADVANCED CONFIGURATION BELOW THIS LINE
# Additional advanced configuration (server context) in saml_sp.server_conf

######### Shared memory zones that keep the SAML-related key-value databases

# Zone for storing AuthnRequest and LogoutRequest message identifiers (ID)
# to prevent replay attacks. (REQUIRED)
# Timeout determines how long the SP waits for a response from the IDP,
# i.e. how long the user authentication process can take.
keyval_zone zone=saml_request_id:1M state=/var/lib/nginx/state/saml_request_id.json timeout=5m;

# Zone for storing SAML Response message identifiers (ID) to prevent replay attacks. (REQUIRED)
# Timeout determines how long the SP keeps IDs to prevent reuse.
keyval_zone zone=saml_response_id:1M state=/var/lib/nginx/state/saml_response_id.json timeout=1h;

# Zone for storing SAML session access information. (REQUIRED)
# Timeout determines how long the SP keeps session access decision (the session lifetime).
keyval_zone zone=saml_session_access:1M state=/var/lib/nginx/state/saml_session_access.json timeout=1h;

# Zone for storing SAML NameID values. (REQUIRED)
# Timeout determines how long the SP keeps NameID values. Must be equal to session lifetime.
keyval_zone zone=saml_name_id:1M state=/var/lib/nginx/state/saml_name_id.json timeout=1h;

# Zone for storing SAML NameID format values. (REQUIRED)
# Timeout determines how long the SP keeps NameID format values. Must be equal to session lifetime.
keyval_zone zone=saml_name_id_format:1M state=/var/lib/nginx/state/saml_name_id_format.json timeout=1h;

# Zone for storing SAML SessionIndex values. (REQUIRED)
# Timeout determines how long the SP keeps SessionIndex values. Must be equal to session lifetime.
keyval_zone zone=saml_session_index:1M state=/var/lib/nginx/state/saml_session_index.json timeout=1h;

# Zone for storing SAML AuthnContextClassRef values. (REQUIRED)
# Timeout determines how long the SP keeps AuthnContextClassRef values. Must be equal to session lifetime.
keyval_zone zone=saml_authn_context_class_ref:1M state=/var/lib/nginx/state/saml_authn_context_class_ref.json timeout=1h;

# Zones for storing SAML attributes values. (OPTIONAL)
# Timeout determines how long the SP keeps attributes values. Must be equal to session lifetime.
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-related variables whose value is looked up by the key (session cookie) in the key-value database.

# Required:
keyval $saml_request_id $saml_request_redeemed zone=saml_request_id; # SAML Request ID
keyval $saml_response_id $saml_response_redeemed zone=saml_response_id; # SAML Response ID
keyval $cookie_auth_token $saml_access_granted zone=saml_session_access; # SAML Access decision
keyval $cookie_auth_token $saml_name_id zone=saml_name_id; # SAML NameID
keyval $cookie_auth_token $saml_name_id_format zone=saml_name_id_format; # SAML NameIDFormat
keyval $cookie_auth_token $saml_session_index zone=saml_session_index; # SAML SessionIndex
keyval $cookie_auth_token $saml_authn_context_class_ref zone=saml_authn_context_class_ref; # SAML AuthnContextClassRef

# Optional:
keyval $cookie_auth_token $saml_attrib_uid zone=saml_attrib_uid;
keyval $cookie_auth_token $saml_attrib_name zone=saml_attrib_name;
keyval $cookie_auth_token $saml_attrib_memberOf zone=saml_attrib_memberOf;

keyval_zone zone=saml_attrib_mail:1M state=/var/lib/nginx/state/saml_attrib_mail.json timeout=1h;
keyval $cookie_auth_token $saml_attrib_mail zone=saml_attrib_mail;

keyval $cookie_auth_token $saml_attrib_objectid zone=saml_attrib_objectid;
keyval_zone zone=saml_attrib_objectid:1M state=/var/lib/nginx/state/saml_attrib_objectid.json timeout=1h;

######### Imports a module that implements SAML SSO and SLO functionality
js_import samlsp from conf.d/saml_sp.js;

4. 3단계: 구성 테스트

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

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

4-1. 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 - - [14/Aug/2023: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 [14/Aug/2023: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) Version/16.1 Safari/605.1.15" "-

NGINX debug.log는 다음과 같이 표시됩니다:

2023/08/14 21:25:49 [info] 27513#27513: *399 js: SAML SP success, creating session _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d

4-2. SP initiated Logout 기능 테스트

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

그림 11: 로그아웃 요청 및 로그아웃 응답에 대한 POST/리다이렉션 바인딩이 있는 SAML SP-initiated SLO

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

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

안전한 로그아웃을 보장하기 위해 SP는 SAML 요청을 시작해야 하며, 이 요청은 IdP에서 확인 및 처리됩니다. 이 작업을 수행하면, 사용자의 세션이 효과적으로 종료되고 IdP는 사용자의 브라우저를 다시 SP로 리다이렉션하는 SAML 응답을 보냅니다.

5. 결론

축하합니다! 이제 NGINX Plus는 인증 프로세스에 또 다른 보안 계층과 편의성을 제공하는 SAML SP 역할을 할 수 있습니다. 이 새로운 기능은 보안과 효율성을 우선시하는 조직을 위해 더욱 강력하고 다재다능한 솔루션으로 거듭난 NGINX Plus의 중요한 진전입니다.

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

지금 바로 NGINX Plus 30일 무료 평가판을 시작하여 SAML을 사용해 볼 수 있습니다. 유용하게 사용하시길 바라며 여러분의 피드백을 환영합니다.

SAML이 포함된 NGINX Plus에 대한 자세한 내용은 아래 리소스에서 확인할 수 있습니다.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.

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

1. NGINX Plus를 SAML Service Provider로 사용

2. 1단계: Microsoft Entra ID를 Identity Provide로 구성하기

3. 2단계: SAML 설정 및 NGINX Plus를 리버스 프록시로 구성하기

4. 3단계: 구성 테스트

4-1. SAML 흐름 확인

4-2. SP initiated Logout 기능 테스트

5. 결론

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

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

이것이 좋아요:

관련

Recent News

NGINX Gateway Fabric: F5 WAF 정책…

NGINX Gateway Fabric: WAFPolicy로 F5 WAF…

NGINX Gateway Fabric WAF 적용 –…

Category

Contact Us

Company

API Gateway

Contacts

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

1. NGINX Plus를 SAML Service Provider로 사용

2. 1단계: Microsoft Entra ID를 Identity Provide로 구성하기

3. 2단계: SAML 설정 및 NGINX Plus를 리버스 프록시로 구성하기

4. 3단계: 구성 테스트

4-1. SAML 흐름 확인

4-2. SP initiated Logout 기능 테스트

5. 결론

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

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

이 글이 도움이 되셨다면 SNS 또는 mail로 공유하셔서 가치를 나누세요!

이것이 좋아요:

관련

Recent News

NGINX Gateway Fabric: F5 WAF 정책…

NGINX Gateway Fabric: WAFPolicy로 F5 WAF…

NGINX Gateway Fabric WAF 적용 –…

Category

Popular Tag

Contact Us

NGINX STORE에서 더 알아보기