Azure Active Directory でのアプリケーションへのシングル サインオンSingle sign-on to applications in Azure Active Directory

シングル サインオン (SSO) によって、ユーザーが Azure Active Directory (Azure AD) 内のアプリケーションにサインオンするときのセキュリティと利便性が向上します。Single sign-on (SSO) adds security and convenience when users sign-on to applications in Azure Active Directory (Azure AD). この記事では、シングル サインオンの方法について説明します。アプリケーションを構成するときに最適な SSO 方法を選択するために役立ちます。This article describes the single sign-on methods, and helps you choose the most appropriate SSO method when configuring your applications.

  • シングル サインオンの使用時には、ユーザーは 1 つのアカウントで、ドメインに参加しているデバイス、会社のリソース、サービスとしてのソフトウェア (SaaS) アプリケーション、および Web アプリケーションに 1 回サインインします。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.

  • シングル サインオンを使用しない場合、ユーザーはアプリケーション固有のパスワードを覚えておき、各アプリケーションにサインインする必要があります。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.

シングル サインオンの方法の選択Choosing a single sign-on method

シングル サインオンのためにアプリケーションを構成する方法はいくつかあります。There are several ways to configure an application for single sign-on. シングル サインオンの方法の選択は、そのアプリケーションが認証に関してどのように構成されているかによって異なります。Choosing a single sign-on method depends on how the application is configured for authentication.

  • クラウド アプリケーションでは、OpenID Connect、OAuth、SAML、パスワードベース、リンク、または無効化の方法をシングル サインオンに使用できます。Cloud applications can use OpenID Connect, OAuth, SAML, password-based, linked, or disabled methods for 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.

このフローチャートは、実際の状況に最適なシングル サインオンの方法を判断するのに役立ちます。This flowchart helps you decide which single sign-on method is best for your situation.

シングル サインオンの方法を選択する

次の表は、シングル サインオンの方法と、詳細情報へのリンクをまとめたものです。The following table summarizes the single sign-on methods, and links to more details.

シングル サインオンの方法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. パスワードベースのシングル サインオンでは、セキュリティで保護されたアプリケーションのパスワードの保存と、Web ブラウザーの拡張機能またはモバイル アプリを使用した再生が可能になります。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 プロバイダー サービスでのシングル サインオンの用に構成されている場合は、リンクされたサインオンを選択します。Choose linked sign-on when the application is configured for single sign-on in another identity provider service. このオプションは、アプリケーションにシングル サインオンを追加するものではありません。This option doesn't add single sign-on to the application. ただし、アプリケーションには、Active Directory フェデレーション サービス (AD FS) などの別のサービスを使って既にシングル サインオンが実装されている場合があります。However, the application might already have single sign-on implemented using another service such as Active Directory Federation Services.
DisabledDisabled クラウドとオンプレミスcloud and on-premises シングル サインオンのためにアプリを構成する準備ができていない場合は、無効化のシングル サインオンを選択します。Choose disabled single sign-on when the app isn't ready to be configured for single sign-on. ユーザーは、そのアプリケーションを起動するたびにユーザー名とパスワードを入力する必要があります。Users need to enter their username and password every time they launch this application.
統合 Windows 認証 (IWA)Integrated Windows Authentication (IWA) オンプレミスのみon-premises only 統合 Windows 認証 (IWA) を使用するアプリケーションまたは要求に対応するアプリケーションには、IWA シングル サインオンを選択します。Choose IWA single sign-on for applications that use Integrated Windows Authentication (IWA), or claims-aware applications. IWA の場合、アプリケーション プロキシ コネクタは、アプリケーションに対して Kerberos 制約付き委任 (KCD) を使用し、ユーザーを認証します。For IWA, the Application Proxy connectors use Kerberos Constrained Delegation (KCD) to authenticate users to the application.
ヘッダーベースHeader-based オンプレミスのみon-premises only アプリケーションが認証のためにヘッダーを使用する場合は、ヘッダー ベースのシングル サインオンを使用します。Use header-based single sign-on when the application uses headers for authentication. ヘッダーベースのシングル サインオンには、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 などの最新のプロトコルを使用して、複数のデバイス プラットフォームでアプリケーションの最適なシングル サイオン エクスペリエンスを実現します。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 により、ユーザーまたは管理者は、MS Graph などの保護されたリソースについて同意することができます。OAuth enables users or admins to grant consent for protected resources like MS Graph. アプリケーション用の SDK を簡単に導入でき、さらにアプリケーションで MS Graph をただちに使用できます。We provide easy to adopt SDKs for your app, and additionally, your app will be ready to use MS Graph.

詳細については、次を参照してください。For more information, see:

SAML SSOSAML SSO

SAML によるシングル サインオンでは、ユーザーの 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 ベースのシングル サインオンでは、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 ベースのシングル サインオンを選択してください。Choose SAML-based single sign-on when the application supports it.

SAML ベースのシングル サインオンは、以下のいずれかのプロトコルを使用するアプリケーションに対してサポートされます。SAML-based single sign-on is supported for applications that use any of these protocols:

  • SAML 2.0SAML 2.0
  • WS-FederationWS-Federation

SAML ベースのシングル サインオンのために SaaS アプリケーションを構成するには、SAML ベースのシングル サインオンを構成することに関するページを参照してください。To configure a SaaS application for SAML-based single sign-on, see Configure SAML-based single sign-on. また、多くのサービスとしてのソフトウェア (SaaS) アプリケーションにはアプリケーション固有のチュートリアルが用意されており、SAML ベースのシングル サインオンの構成が順を追って説明されています。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-Federation のためにアプリケーションを構成するには、SAML ベースのシングル サインオンのためにアプリケーションを構成する場合と同じガイダンスに従って、「SAML ベースのシングル サインオンを構成する」を参照してください。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 ベースのシングル サインオンのためにオンプレミス アプリケーションを構成するには、「アプリケーション プロキシを使用したオンプレミスのアプリケーションに対する SAML シングル サインオン」を参照してください。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 プロトコルの詳細については、「シングル サインオンの 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.

パスワード ベースのシングル サインオンでは、アプリケーションによって提供される既存の認証プロセスが使用されます。Password-based single sign-on uses the existing authentication process provided by the application. アプリケーションでパスワードによるシングル サインオンを有効にすると、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.

パスワードベースのシングル サインオンは以下の場合に選択します。Choose password-based single sign-on when:

  • アプリケーションが SAML シングル サインオン プロトコルをサポートしていない。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 ベースのサインイン ページを持つどのクラウド ベース アプリケーションでもサポートされます。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:

  • Internet Explorer 11 - Windows 7 以降Internet Explorer 11 on Windows 7 or later
  • Microsoft Edge - Windows 10 Anniversary Edition 以降Microsoft Edge on Windows 10 Anniversary Edition or later
  • Chrome - Windows 7 以降、MacOS X 以降Chrome on Windows 7 or later, and on MacOS X or later
  • Firefox 26.0 以降 - Windows XP SP2 以降、Mac os X 10.6 以降Firefox 26.0 or later on Windows XP SP2 or later, and on Mac OS X 10.6 or later

パスワード ベースのシングル サインオンのためにクラウド アプリケーションを構成するには、「パスワード シングル サインオンに対応するようにアプリケーションを構成する」を参照してください。To configure a cloud application for password-based single sign-on, see Configure the application for password 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 は、Web ブラウザーの拡張機能またはモバイル アプリを介して安全にユーザーの資格情報を渡します。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. しかし技術的には、Web デバッグ ツールを使用して資格情報を知ることができます。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 は、リンクされたサインオンによって、既に別のサービスでのシングル サインオンのために構成されているシングル サインオンをアプリケーションに提供できます。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. たとえばユーザーは、Active Directory フェデレーション サービス 2.0 (AD FS) でシングル サインオン用に構成されているアプリケーションを、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.

アプリケーション移行の場合のリンクされたサインオン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.

リンクされているアプリケーションでいったんユーザーが認証されたら、エンドユーザーにシングル サインオン アクセスが提供される前に、アカウント レコードを作成する必要があります。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

無効化モードは、そのアプリケーションに対してシングル サインオンが使用されないことを意味します。Disabled mode means single sign-on isn't used for the application. シングル サインオンが無効になっている場合、ユーザーは 2 回認証することが必要な場合があります。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.

シングル サインオン無効化モードは以下のために使用します。Use disabled single sign-on mode:

  • このアプリケーションを Azure AD シングル サインオンと統合する準備ができていない場合、または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.

統合 Windows 認証 (IWA) による SSOIntegrated Windows Authentication (IWA) SSO

アプリケーション プロキシは、統合 Windows 認証 (IWA) を使用するアプリケーションや要求対応のアプリケーションに対するシングル サインオン (SSO) を提供します。Application Proxy provides single sign-on (SSO) to applications that use Integrated Windows Authentication (IWA), or claims-aware applications. アプリケーションで IWA が使用されている場合、アプリケーション プロキシは Kerberos の制約付き委任 (KCD) を使用して、アプリケーションに対する認証を行います。If your application uses IWA, Application Proxy authenticates to the application by using Kerberos Constrained Delegation (KCD). Azure Active Directory を信頼している要求対応のアプリケーションでは、ユーザーは Azure AD を使用して既に認証されているため、シングル サインオンが機能します。For a claims-aware application that trusts Azure Active Directory, single sign-on works because the user was already authenticated by using Azure AD.

統合 Windows 認証のシングル サインオン モードは以下の場合に選択します。Choose Integrated Windows Authentication single sign-on mode:

  • IWA を使用して認証するオンプレミス アプリに対するシングル サインオンを提供する場合。To provide single sign-on to an on-premises app that authenticates with IWA.

IWA のためのオンプレミス アプリの構成については、アプリケーション プロキシを使用して、アプリケーションに対するシングル サインオンのための Kerberos 制約付き委任を行うことに関するページを参照してください。To configure an on-premises app for IWA, see Kerberos Constrained Delegation for single sign-on to your applications with Application Proxy.

KCD を使ったシングル サインオンのしくみ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 AAD 認証のフロー図

  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 との間で、Kerberos の制約付き委任 (KCD) ネゴシエーションを使用します。このとき、ユーザーの偽装によってアプリケーションに対する 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

ヘッダー ベースのシングル サインオンは、認証のために 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.

ヘッダーベースのシングル サインオンは以下の場合に選択します。Choose header-based single sign-on when:

  • アプリケーションに対してアプリケーション プロキシと PingAccess が構成されているApplication Proxy and PingAccess are configured for the application

ヘッダー ベースの認証を構成するには、アプリケーション プロキシを使用したシングル サインオン用のヘッダー ベースの認証に関する記事を参照してください。To configure header-based authentication, see Header-based authentication for single sign-on with Application Proxy.

PingAccess for Azure AD とはWhat is PingAccess for Azure AD?

ユーザーは PingAccess for Azure AD を使用して、認証にヘッダーを使用するアプリケーションへのアクセスとシングル サインオンを実現できます。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.