Azure Active Directory의 애플리케이션에 대한 Single Sign-OnSingle sign-on to applications in Azure Active Directory

SSO(Single Sign-On)는 사용자가 Azure AD(Azure Active Directory)의 애플리케이션에 로그인할 때 보안 및 편리함을 제공합니다.Single sign-on (SSO) adds security and convenience when users sign-on to applications in Azure Active Directory (Azure AD). 이 문서는 Single Sign-On 방법을 설명하고, 애플리케이션을 구성할 때 가장 적합한 SSO 방법을 선택하는 데 유용합니다.This article describes the single sign-on methods, and helps you choose the most appropriate SSO method when configuring your applications.

  • Single Sign-On을 사용하면 사용자는 하나의 계정으로 한 번 로그인으로 도메인 가입 디바이스, 회사 리소스, SaaS(Software as a Service) 애플리케이션 및 웹 애플리케이션에 액세스할 수 있습니다.With single sign-on, users sign in once with one account to access domain-joined devices, company resources, software as a service (SaaS) applications, and web applications. 로그인한 후 사용자는 Office 365 포털 또는 Azure AD MyApps 액세스 패널에서 애플리케이션을 시작할 수 있습니다.After signing in, the user can launch applications from the Office 365 portal or the Azure AD MyApps access panel. 관리자는 사용자 계정 관리를 중앙 집중화하고, 그룹 멤버 자격에 따라 애플리케이션에 대한 사용자 액세스를 자동으로 추가하거나 제거할 수 있습니다.Administrators can centralize user account management, and automatically add or remove user access to applications based on group membership.

  • Single Sign-On을 사용하지 않으면 사용자는 애플리케이션별 암호를 기억하고 각 애플리케이션마다 로그인해야 합니다.Without single sign-on, users must remember application-specific passwords and sign in to each application. IT 직원은 Office 365, Box 및 Salesforce와 같은 각 애플리케이션에 대한 사용자 계정을 만들고 업데이트해야 합니다.IT staff needs to create and update user accounts for each application such as Office 365, Box, and Salesforce. 사용자가 암호를 기억해야 하는 것과 동시에 각 애플리케이션에 로그인하는 시간도 소비됩니다.Users need to remember their passwords, plus spend the time to sign in to each application.

Single Sign-On 방법 선택Choosing a single sign-on method

Single Sign-On을 위해 애플리케이션을 구성하는 방법은 여러 가지가 있습니다.There are several ways to configure an application for single sign-on. Single Sign-On 방법을 선택하는 것은 애플리케이션이 인증에 대해 어떻게 구성되었는지에 따라 달라집니다.Choosing a single sign-on method depends on how the application is configured for authentication.

  • 클라우드 애플리케이션은 Single Sign-On에 대해 OpenID Connect, OAuth, SAML, 암호 기반, 연결됨 또는 사용 안 함 방법을 사용할 수 있습니다.Cloud applications can use OpenID Connect, OAuth, SAML, password-based, linked, or disabled methods for single sign-on.
  • 온-프레미스 애플리케이션은 Single Sign-On에 대해 암호 기반, Windows 통합 인증, 헤더 기반, 연결됨 또는 사용 안 함 방법을 사용할 수 있습니다.On-premises applications can use password-based, Integrated Windows Authentication, header-based, linked, or disabled methods for single sign-on. 온-프레미스 선택은 애플리케이션 프록시에 대해 애플리케이션을 구성할 때 작동합니다.The on-premises choices work when applications are configured for Application Proxy.

이 순서도는 사용자 상황에 가장 적합한 Single Sign-On 방법을 결정하는 데 도움이 됩니다.This flowchart helps you decide which single sign-on method is best for your situation.

Single Sign-On 방법에 대 한 의사 결정 순서도

다음 표에는 Single Sign-On 방법이 요약되어 있으며 더 자세한 정보로 이어집니다.The following table summarizes the single sign-on methods, and links to more details.

Single Sign-On 방법Single sign-on method 애플리케이션 종류Application types 사용 시기When to use
OpenID Connect 및 OAuthOpenID Connect and OAuth 클라우드 전용cloud only 새 애플리케이션을 개발하는 경우 OpenID Connect 및 OAuth를 사용합니다.Use OpenID Connect and OAuth when developing a new application. 이 프로토콜은 애플리케이션 구성을 간소화하고, 사용하기 쉬운 SDK를 보유하며, 애플리케이션에서 MS Graph를 사용하도록 설정합니다.This protocol simplifies application configuration, has easy-to-use SDKs, and enables your application to use MS Graph.
SAMLSAML 클라우드 및 온-프레미스cloud and on-premises OpenID Connect 또는 OAuth를 사용하지 않는 기존 애플리케이션에 대해 언제나 사용 가능한 SAML을 선택합니다.Choose SAML whenever possible for existing applications that do not use OpenID Connect or OAuth. SAML은 SAML 프로토콜 중 하나를 사용하여 인증하는 애플리케이션에 대해 작동합니다.SAML works for applications that authenticate using one of the SAML protocols.
암호 기반Password-based 클라우드 및 온-프레미스cloud and on-premises 애플리케이션이 사용자 이름 및 암호를 사용하여 인증하는 경우 암호 기반을 선택합니다.Choose password-based when the application authenticates with username and password. 암호 기반 Single Sign-On을 사용하면 웹 브라우저 확장 또는 모바일 앱을 사용하여 안전하게 애플리케이션 암호를 스토리지하고 재생할 수 있습니다.Password-based single sign-on enables secure application password storage and replay using a web browser extension or mobile app. 이 방법은 애플리케이션에서 제공하는 기존 로그인 프로세스를 사용하지만, 관리자가 암호를 관리할 수 있습니다.This method uses the existing sign-in process provided by the application, but enables an administrator to manage the passwords.
연결됨Linked 클라우드 및 온-프레미스cloud and on-premises 응용 프로그램이 다른 id 공급자 서비스에서 Single Sign-On 하도록 구성 된 경우 연결 된 로그온을 선택 합니다.Choose linked sign-on when the application is configured for single sign-on in another identity provider service. 이 옵션은 애플리케이션에 Single Sign-On을 추가하지 않습니다.This option doesn't add single sign-on to the application. 하지만 애플리케이션에 이미 Active Directory Federation Services와 같은 다른 서비스를 사용하여 Single Sign-On이 구현되어 있을 수도 있습니다.However, the application might already have single sign-on implemented using another service such as Active Directory Federation Services.
사용 안 함Disabled 클라우드 및 온-프레미스cloud and on-premises 앱을 Single Sign-On에 대해 구성할 준비가 되지 않은 경우 사용 안 함 Single Sign-On을 선택합니다.Choose disabled single sign-on when the app isn't ready to be configured for single sign-on. 이 모드는 앱을 만들 때의 기본값입니다.This mode is the default when you create the app.
IWA(Windows 통합 인증)Integrated Windows Authentication (IWA) 온-프레미스만on-premises only IWA Single Sign-On 방법은 IWA(Windows 통합 인증)를 사용하는 애플리케이션 또는 클레임 인식 애플리케이션에 선택합니다.Choose IWA single sign-on for applications that use Integrated Windows Authentication (IWA), or claims-aware applications. IWA의 경우 애플리케이션 프록시 커넥터는 애플리케이션에 사용자를 인증하는 데 KCD(Kerberos 제한된 위임)를 사용합니다.For IWA, the Application Proxy connectors use Kerberos Constrained Delegation (KCD) to authenticate users to the application.
헤더 기반Header-based 온-프레미스만on-premises only 애플리케이션이 인증에 헤더를 사용하는 경우 헤더 기반 Single Sign-On을 사용합니다.Use header-based single sign-on when the application uses headers for authentication. 헤더 기반 Single Sign-On에는 Azure AD용 PingAccess가 필요합니다.Header-based single sign-on requires PingAccess for Azure AD. 애플리케이션 프록시는 Azure AD를 사용하여 사용자를 인증한 다음, 커넥터 서비스를 통해 트래픽을 전달합니다.Application Proxy uses Azure AD to authenticate the user and then passes traffic through the connector service.

OpenID Connect 및 OAuthOpenID Connect and OAuth

새 애플리케이션을 개발하는 경우 OpenID Connect 및 OAuth와 같은 최신 프로토콜을 사용하여 여러 디바이스 플랫폼에서 애플리케이션에 가장 적합한 Single Sign-On 환경을 달성할 수 있습니다.When developing new applications, use modern protocols like OpenID Connect and OAuth to achieve the best single sign-on experience for your app across multiple device platforms. OAuth를 사용 하면 사용자나 관리자가 Microsoft Graph와 같은 보호 된 리소스에 대 한 동의를 부여할 수 있습니다.OAuth enables users or admins to grant consent for protected resources like Microsoft Graph. 앱에 대 한 sdk 를 쉽게 채택할 수 있으며 앱이 Microsoft Graph사용할 준비가 됩니다.We provide easy to adopt SDKs for your app, and additionally, your app will be ready to use Microsoft Graph.

자세한 내용은 다음을 참조하세요.For more information, see:

SAML SSOSAML SSO

SAML Single Sign-On을 사용하는 Azure AD는 사용자의 Azure AD 계정을 사용하여 애플리케이션에 인증합니다.With SAML single sign-on, Azure AD authenticates to the application by using the user's Azure AD account. Azure AD는 연결 프로토콜을 통해 애플리케이션에 로그온 정보를 통신합니다.Azure AD communicates the sign-on information to the application through a connection protocol. SAML 기반 Single Sign-On을 사용하면 SAML 클레임에서 정의하는 규칙에 따라 사용자를 특정 애플리케이션 역할에 매핑할 수 있습니다.With SAML-based single sign-on, you can map users to specific application roles based on rules you define in your SAML claims.

애플리케이션에서 지원하는 경우 SAML 기반 Single Sign-On을 선택합니다.Choose SAML-based single sign-on when the application supports it.

SAML 기반 Single Sign-On은 다음과 같은 프로토콜을 사용하는 애플리케이션에 대해 지원됩니다.SAML-based single sign-on is supported for applications that use any of these protocols:

  • SAML 2.0SAML 2.0
  • WS-FederationWS-Federation

SAML 기반 Single Sign-On에 대 한 SaaS 응용 프로그램을 구성 하려면 saml 기반 Single Sign-On 구성을 참조 하세요.To configure a SaaS application for SAML-based single sign-on, see Configure SAML-based single sign-on. 또한 다양한 SaaS(Software as a Service) 애플리케이션에는 SAML 기반 Single Sign-On에 대한 구성을 단계별로 안내하는 애플리케이션 관련 자습서가 있습니다.Also, many Software as a Service (SaaS) applications have an application-specific tutorial that step you through the configuration for SAML-based single sign-on.

WS 페더레이션을 위한 응용 프로그램을 구성 하려면 동일한 지침에 따라 SAML 기반 Single Sign-On에 대 한 응용 프로그램을 구성 합니다. saml 기반 Single Sign-On 구성을 참조 하세요.To configure an application for WS-Federation, follow the same guidance to configure application for SAML-based single sign-on, see Configure SAML-based single sign-on. Azure AD를 사용 하도록 응용 프로그램을 구성 하는 단계에서 WS-FEDERATION 끝점에 대 한 Azure AD 로그인 URL을 대체 해야 합니다 https://login.microsoftonline.com/<tenant-ID>/wsfed.In the step to configure the application to use Azure AD, you will need to replace the Azure AD login URL for the WS-Federation end-point https://login.microsoftonline.com/<tenant-ID>/wsfed.

SAML 기반 Single Sign-On에 대 한 온-프레미스 응용 프로그램을 구성 하려면 응용 프로그램 프록시를 사용 하는 온-프레미스 응용 프로그램에 대 한 saml single sign-on을 참조 하세요.To configure an on-premises application for SAML-based single sign-on, see SAML single-sign-on for on-premises applications with Application Proxy.

SAML 프로토콜에 대한 자세한 정보는 Single Sign-On SAML 프로토콜을 참조하세요.For more information about the SAML protocol, see Single sign-on SAML protocol.

암호 기반 SSOPassword-based SSO

암호 기반 로그온을 사용하는 경우 사용자는 애플리케이션에 처음 액세스할 때 사용자 이름 및 암호를 사용하여 애플리케이션에 로그온합니다.With password-based sign-on, users sign on to the application with a username and password the first time they access it. 첫 번째 로그온 후에는 Azure AD가 사용자 이름 및 암호를 애플리케이션에 제공합니다.After the first sign-on, Azure AD supplies the username and password to the application.

암호 기반 Single Sign-On은 애플리케이션에서 제공한 기존 인증 프로세스를 사용합니다.Password-based single sign-on uses the existing authentication process provided by the application. 애플리케이션에서 암호 Single Sign-On을 사용하도록 설정하면 Azure AD는 애플리케이션에 대한 사용자 이름 및 암호를 수집하고 안전하게 저장합니다.When you enable password single sign-on for an application, Azure AD collects and securely stores user names and passwords for the application. 사용자 자격 증명은 암호화된 상태로 디렉터리에 저장됩니다.User credentials are stored in an encrypted state in the directory.

다음과 같은 경우에 암호 기반 Single Sign-On을 선택합니다.Choose password-based single sign-on when:

  • 애플리케이션이 SAML Single Sign-On 프로토콜을 지원하지 않습니다.An application doesn't support SAML single sign-on protocol.
  • 애플리케이션이 액세스 토큰 및 헤더 대신 사용자 이름과 암호를 사용하여 인증합니다.An application authenticates with a username and password instead of access tokens and headers.

HTML 기반 로그인 페이지가 있는 클라우드 기반 애플리케이션에 암호 기반 Single Sign-On이 지원됩니다.Password-based single sign-on is supported for any cloud-based application that has an HTML-based sign-in page. 사용자는 다음 브라우저를 사용할 수 있습니다.The user can use any of the following browsers:

  • Windows 7 이상의 Internet Explorer 11Internet Explorer 11 on Windows 7 or later

    참고

    Internet Explorer는 지원이 제한되며, 새 소프트웨어 업데이트가 더 이상 수신되지 않습니다.Internet Explorer is on limited support and no longer receives new software updates. Microsoft Edge가 권장되는 브라우저입니다.Microsoft Edge is the recommended browser.

  • Windows 10 Anniversary Edition 이상의 Microsoft EdgeMicrosoft Edge on Windows 10 Anniversary Edition or later

  • IOS 및 Android 용 Microsoft EdgeMicrosoft Edge for iOS and Android

  • Intune Managed BrowserIntune Managed Browser

  • Windows 7 이상 및 Mac OS X 이상 ChromeChrome on Windows 7 or later, and on MacOS X or later

  • Windows XP SP2 이상 및 Mac OS X 10.6 이상 Firefox 26.0 이상Firefox 26.0 or later on Windows XP SP2 or later, and on Mac OS X 10.6 or later

암호 기반 Single Sign-On에 대 한 클라우드 응용 프로그램을 구성 하려면 암호 구성 Single Sign-On을 참조 하세요.To configure an cloud application for password-based single sign-on, see Configure password single sign-on.

애플리케이션 프록시를 통해 Single Sign-On에 대한 온-프레미스 애플리케이션을 구성하려면 애플리케이션 프록시를 사용하여 Single Sign-On에 대한 암호 자격 증명 모음 설정을 참조하세요To configure an on-premises application for single sign-on through Application Proxy, see Password vaulting for single sign-on with Application Proxy

암호 기반 SSO에 대한 인증 작동 방식How authentication works for password-based SSO

애플리케이션에 사용자를 인증하기 위해 Azure AD는 디렉터리에서 사용자의 자격 증명을 검색하여 애플리케이션의 로그온 페이지에 입력합니다.To authenticate a user to an application, Azure AD retrieves the user's credentials from the directory and enters them into the application's sign-on page. Azure AD는 웹 브라우저 확장 또는 모바일 앱을 통해 사용자 자격 증명을 안전하게 전달합니다.Azure AD securely passes the user credentials via a web browser extension or mobile app. 이 프로세스에서는 사용자 자격 증명을 관리자가 관리할 수 있으며, 사용자가 자신의 암호를 기억할 필요가 없습니다.This process enables an administrator to manage user credentials, and doesn't require users to remember their password.

중요

자동화된 로그인 프로세스 도중 사용자에 의해 자격 증명이 난독 처리됩니다.The credentials are obfuscated from the user during the automated sign-on process. 그러나 자격 증명은 웹 디버깅 도구를 사용하여 검색할 수 있습니다.However, the credentials are discoverable by using web-debugging tools. 사용자 및 관리자는 사용자가 직접 입력한 자격 증명과 동일한 보안 정책을 따라야 합니다.Users and administrators need to follow the same security policies as if credentials were entered directly by the user.

암호 기반 SSO에 대한 자격 증명 관리Managing credentials for password-based SSO

각 애플리케이션에 대한 암호는 Azure AD 관리자 또는 사용자가 관리할 수 있습니다.Passwords for each application can either be managed by the Azure AD administrator or by the users.

Azure AD 관리자가 자격 증명을 관리하는 경우:When the Azure AD administrator manages the credentials:

  • 사용자는 다시 설정하거나 사용자 이름 및 암호를 기억할 필요가 없습니다.The user doesn't need to reset or remember the user name and password. 사용자는 액세스 패널에서 클릭하거나 제공된 링크를 통해 애플리케이션에 액세스할 수 있습니다.The user can access the application by clicking on it in their access panel or via a provided link.
  • 관리자는 자격 증명에서 관리 작업을 수행할 수 있습니다.The administrator can do management tasks on the credentials. 예를 들어, 관리자는 사용자 그룹 멤버 자격 및 직원 상태에 따라 애플리케이션 액세스를 업데이트할 수 있습니다.For example, the administrator can update application access according to user group memberships and employee status.
  • 관리자는 관리 자격 증명을 사용하여 많은 사용자들이 공유하는 애플리케이션에 대한 액세스를 제공할 수 있습니다.The administrator can use administrative credentials to provide access to applications shared among many users. 예를 들어 관리자는 애플리케이션에 액세스할 수 있는 모든 사용자가 소셜 미디어나 문서 공유 애플리케이션에 액세스할 수 있도록 허용할 수 있습니다.For example, the administrator can allow everyone who can access an application to have access to a social media or document sharing application.

최종 사용자가 자격 증명을 관리하는 경우:When the end user manages the credentials:

  • 사용자는 필요에 따라 해당 암호를 업데이트 또는 삭제하여 관리할 수 있습니다.Users can manage their passwords by updating or deleting them as needed.
  • 관리자는 계속 애플리케이션에 대한 새 자격 증명을 설정할 수 있습니다.Administrators are still able to set new credentials for the application.

연결된 로그온Linked sign-on

연결된 로그온을 통해 Azure AD는 이미 다른 서비스에서 Single Sign-On에 대해 구성된 애플리케이션에 Single Sign-On을 제공할 수 있습니다.Linked sign-on enables Azure AD to provide single sign-on to an application that is already configured for single sign-on in another service. 연결된 애플리케이션은 Office 365 포털 또는 Azure AD MyApps 포털에서 최종 사용자에게 표시될 수 있습니다.The linked application can appear to end users in the Office 365 portal or Azure AD MyApps portal. 예를 들어, 사용자는 AD FS(Active Directory Federation Services) 2.0의 Single Sign-On에 대해 구성된 애플리케이션을 Office 365 포털에서 시작할 수 있습니다.For example, a user can launch an application that is configured for single sign-on in Active Directory Federation Services 2.0 (AD FS) from the Office 365 portal. 추가적인 보고도 Office 365 포털 또는 Azure AD MyApps 포털에서 실행되는 연결된 애플리케이션에 제공됩니다.Additional reporting is also available for linked applications that are launched from the Office 365 portal or the Azure AD MyApps portal. 연결 된 로그온을 위해 응용 프로그램을 구성 하려면 연결 된 로그온 구성을 참조 하세요.To configure an application for linked sign-on, see Configure linked sign-on.

응용 프로그램 마이그레이션에 대 한 연결 된 로그온Linked sign-on for application migration

연결 된 로그온은 일정 기간 동안 응용 프로그램을 마이그레이션하는 동안 일관 된 사용자 환경을 제공할 수 있습니다.Linked sign-on can provide a consistent user experience while you migrate applications over a period of time. Azure Active Directory로 응용 프로그램을 마이그레이션하는 경우 연결 된 로그온을 사용 하 여 마이그레이션하려는 모든 응용 프로그램에 대 한 링크를 빠르게 게시할 수 있습니다.If you're migrating applications to Azure Active Directory, you can use linked sign-on to quickly publish links to all the applications you intend to migrate. 사용자는 MyApps 포털 또는 Office 365 애플리케이션 시작 관리자에서 모든 링크를 찾을 수 있습니다.Users can find all the links in the MyApps portal or the Office 365 application launcher. 사용자는 연결된 애플리케이션 또는 마이그레이션된 애플리케이션에 액세스하는 것을 알지 못합니다.Users won't know they're accessing a linked application or a migrated application.

사용자가 연결된 애플리케이션을 사용하여 인증하고 나면, 최종 사용자에게 Single Sign-On 액세스를 제공하기 전에 먼저 계정 레코드를 만들어야 합니다.Once a user has authenticated with a linked application, an account record needs to be created before the end user is provided single sign-on access. 이 계정 레코드의 프로비저닝은 자동으로 발생하거나 관리자에 의해 수동으로 발생할 수 있습니다.Provisioning this account record can either occur automatically, or it can occur manually by an administrator.

사용 안 함 SSODisabled SSO

사용 안 함 모드란 Single Sign-On이 애플리케이션에 사용되지 않았음을 의미합니다.Disabled mode means single sign-on isn't used for the application. Single Sign-On이 사용하지 않도록 설정되면 사용자는 두 번 인증해야 할 수도 있습니다.When single sign-on is disabled, users might need to authenticate twice. 먼저 사용자는 Azure AD에 인증한 다음, 애플리케이션에 로그인합니다.First, users authenticate to Azure AD, and then they sign in to the application.

다음과 같은 경우 사용 안 함 Single Sign-On 모드를 사용합니다.Use disabled single sign-on mode:

  • Azure AD Single Sign-On을 사용하여 이 애플리케이션을 통합할 준비가 되지 않은 경우 또는If you're not ready to integrate this application with Azure AD single sign-on, or
  • 애플리케이션의 다른 측면을 테스트하는 경우 또는If you're testing other aspects of the application, or
  • 사용자가 인증할 필요가 없는 온-프레미스 애플리케이션에 대한 보안 계층입니다.As a layer of security to an on-premises application that doesn't require users to authenticate. 사용 안 함을 사용하는 사용자는 인증해야 합니다.With disabled, the user needs to authenticate.

SP 시작 SAML 기반 Single Sign-On에 대해 응용 프로그램을 구성 했으며 SSO 모드를 사용 안 함으로 변경 하면 사용자가 MyApps 포털 외부에서 응용 프로그램에 서명 하는 것을 중지 하지 않습니다.Note that if you have configured the application for SP-initiated SAML based single sign-on and you change the SSO mode to disable, it won't stop users from signing to the application outside the MyApps portal. 이를 위해 사용자가 로그인 할 수 있는 기능을 사용 하지 않도록 설정 해야 합니다 .To achieve this, you need to disable the ability for users to sign-in

IWA(Windows 통합 인증) SSOIntegrated Windows Authentication (IWA) SSO

애플리케이션 프록시Windows 통합 인증(IWA) 또는 클레임 인식 애플리케이션을 사용하는 애플리케이션에 SSO(Single Sign-On)를 제공합니다.Application Proxy provides single sign-on (SSO) to applications that use Integrated Windows Authentication (IWA), or claims-aware applications. 애플리케이션에서 IWA를 사용하는 경우 애플리케이션 프록시는 KCD(Kerberos 제한 위임)를 사용하여 애플리케이션에 인증합니다.If your application uses IWA, Application Proxy authenticates to the application by using Kerberos Constrained Delegation (KCD). Azure Active Directory를 신뢰하는 클레임 인식 애플리케이션의 경우 사용자가 이미 Azure AD를 사용하여 인증되었으므로 Single Sign-On이 작동합니다.For a claims-aware application that trusts Azure Active Directory, single sign-on works because the user was already authenticated by using Azure AD.

IWA를 사용 하 여 인증 하는 온-프레미스 앱에 Single Sign-On를 제공 하려면 Windows 통합 인증 Single Sign-On 모드를 선택 합니다.Choose Integrated Windows Authentication single sign-on mode to provide single sign-on to an on-premises app that authenticates with IWA.

IWA에 대해 온-프레미스 앱을 구성하려면 애플리케이션 프록시를 사용하여 애플리케이션에 Single Sign-On에 대한 Kerberos 제한 위임을 참조하세요.To configure an on-premises app for IWA, see Kerberos Constrained Delegation for single sign-on to your applications with Application Proxy.

KCD를 사용하는 Single Sign-On 작동 방식How single sign-on with KCD works

이 다이어그램은 IWA를 사용하는 온-프레미스 애플리케이션에 사용자가 액세스할 때 흐름을 설명합니다.This diagram explains the flow when a user accesses an on-premises application that uses IWA.

Microsoft Azure AD 인증 흐름 다이어그램

  1. 사용자는 응용 프로그램 프록시를 통해 온-프레미스 응용 프로그램에 액세스할 수 있는 URL을 입력 합니다.The user enters the URL to access the on premises application through Application Proxy.
  2. 애플리케이션 프록시는 사전 인증을 위해 Azure AD 인증 서비스에 요청을 리디렉션합니다.Application Proxy redirects the request to Azure AD authentication services to preauthenticate. 이 시점에서 Azure AD는 다단계 인증 등, 모든 적용 가능한 인증 및 권한 부여 정책을 적용합니다.At this point, Azure AD applies any applicable authentication and authorization policies, such as multifactor authentication. 사용자가 확인되면 Azure AD에서 토큰을 만들어서 사용자에게 보냅니다.If the user is validated, Azure AD creates a token and sends it to the user.
  3. 사용자는 토큰을 애플리케이션 프록시로 전달합니다.The user passes the token to Application Proxy.
  4. 애플리케이션 프록시는 토큰의 유효성을 검사하고 토큰에서 UPN(사용자 주체 이름)을 검색합니다.Application Proxy validates the token and retrieves the User Principal Name (UPN) from the token. 그런 다음, 이중으로 인증된 보안 채널을 통해 커넥터에 요청, UPN 및 SPN(서비스 주체 이름)을 보냅니다.It then sends the request, the UPN, and the Service Principal Name (SPN) to the Connector through a dually authenticated secure channel.
  5. 커넥터는 온-프레미스 AD와 함께 KCD (Kerberos 제한 위임) 협상을 사용 하며, 사용자를 가장 하 여 응용 프로그램에 대 한 Kerberos 토큰을 가져옵니다.The connector uses Kerberos Constrained Delegation (KCD) negotiation with the on premises AD, impersonating the user to get a Kerberos token to the application.
  6. Active Directory는 애플리케이션에 대한 Kerberos 토큰을 커넥터로 보냅니다.Active Directory sends the Kerberos token for the application to the connector.
  7. 커넥터는 AD에서 받은 Kerberos 토큰을 사용하여 원래 요청을 애플리케이션 서버에 보냅니다.The connector sends the original request to the application server, using the Kerberos token it received from AD.
  8. 애플리케이션은 응답을 커넥터로 보냅니다. 그러면 해당 응답이 애플리케이션 프록시 서비스를 거쳐 마지막으로 사용자에게 반환됩니다.The application sends the response to the connector, which is then returned to the Application Proxy service and finally to the user.

헤더 기반 SSOHeader-based SSO

헤더 기반 Single Sign-On은 인증에 HTTP 헤더를 사용하는 애플리케이션에 작동합니다.Header-based single sign-on works for applications that use HTTP headers for authentication. 이 로그온 방법은 PingAccess라고 하는 타사 인증 서비스를 사용합니다.This sign-on method uses a third-party authentication service called PingAccess. 사용자만 Azure AD에 인증해야 합니다.A user only needs to authenticate to Azure AD.

응용 프로그램 프록시 및 인터넷 액세스가 응용 프로그램에 대해 구성 된 경우 헤더 기반 Single Sign-On를 선택 합니다.Choose header-based single sign-on when Application Proxy and PingAccess are configured for the application.

헤더 기반 인증을 구성하려면 애플리케이션 프록시를 사용하여 Single Sign-On에 대한 헤더 기반 인증을 참조하세요.To configure header-based authentication, see Header-based authentication for single sign-on with Application Proxy.

Azure AD용 PingAccess는 무엇입니까?What is PingAccess for Azure AD?

Azure AD에 PingAccess를 사용하면 사용자는 인증에 헤더를 사용하는 애플리케이션에 액세스 및 Single Sign-On을 사용할 수 있습니다.Using PingAccess for Azure AD, users can access and single sign-on to applications that use headers for authentication. 애플리케이션 프록시는 이러한 애플리케이션을 Azure AD를 사용하여 액세스를 인증한 다음, 커넥터 서비스를 통해 트래픽을 전달하는 방식으로 다른 앱과 유사하게 처리합니다.Application Proxy treats these applications like any other, using Azure AD to authenticate access and then passing traffic through the connector service. 인증이 발생한 후 PingAccess 서비스는 Azure AD 액세스 토큰을 애플리케이션에 전송되는 헤더 형식으로 변환합니다.After authentication occurs, the PingAccess service translates the Azure AD access token into a header format that is sent to the application.

사용자는 회사 애플리케이션을 사용하기 위해 로그인할 때 다른 점을 알아차리지 못합니다.Your users won’t notice anything different when they sign in to use your corporate applications. 여전히 어디에서든지 모든 디바이스에서 작업할 수 있습니다.They can still work from anywhere on any device. 애플리케이션 프록시 커넥터는 모든 애플리케이션에 원격 트래픽을 보내므로 계속해서 부하 분산을 자동으로 수행합니다.The Application Proxy connectors direct remote traffic to all applications, and they’ll continue to load balance automatically.

PingAccess에 대한 라이선스를 가져오려면 어떻게 해야 하나요?How do I get a license for PingAccess?

이 시나리오는 Azure AD 및 PingAccess 간의 파트너 관계를 통해 제공되므로 두 서비스에 대한 라이선스가 필요합니다.Since this scenario is offered through a partnership between Azure AD and PingAccess, you need licenses for both services. 그러나 Azure AD Premium 구독에는 최대 20개의 애플리케이션을 보장하는 기본 PingAccess 라이선스가 포함되어 있습니다.However, Azure AD Premium subscriptions include a basic PingAccess license that covers up to 20 applications. 헤더 기반 애플리케이션을 20개 넘게 게시해야 하는 경우 PingAccess에서 라이선스를 추가로 구입할 수 있습니다.If you need to publish more than 20 header-based applications, you can acquire an additional license from PingAccess.

자세한 내용은 Azure Active Directory 버전을 참조하세요.For more information, see Azure Active Directory editions.