> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> 既存のエンタープライズディレクトリサービスを拡張したい大規模な組織における、B2E のアーキテクチャシナリオを説明します。

# Business to Employees

B2E (Business to Employees) シナリオは、従業員ユーザーが利用するアプリケーションに関するものです。これは、ユーザーが自分自身のためではなく、雇用主、大学、または所属するグループなどの組織を代表して行動することが一般的な場合を対象とするアプリケーションです。

このようなアプリケーションのうち、組織が独自に開発したものでは、認証を外部化するために OIDC/<Tooltip tip="OAuth 2.0: 認可のプロトコルおよびワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth">OAuth</Tooltip> プロトコルが使われることがあります。一方で、購入したアプリケーションでは、多くの場合 <Tooltip tip="Security Assertion Markup Language (SAML): パスワードなしで 2 者間の認証情報交換を可能にする標準化されたプロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=SAML">SAML</Tooltip> プロトコルが使用されます。いずれの場合も、企業は通常、企業ユーザーの認証に、SAML <Tooltip tip="Identity Provider (IdP): デジタルアイデンティティを保存および管理するサービス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Identity+Provider">IDプロバイダー</Tooltip>、ADFS、Google Workspace、Azure AD などのエンタープライズ接続、または AD や OpenLDAP のようなディレクトリサービスを利用したいと考えます。カスタム DB が使われることもありますが、その頻度は高くありません。

B2E 環境向けに、Auth0 と連携するアプリケーションを作成または統合する企業には、このシナリオに共通する要件がいくつかあります。このガイドでは、B2E アプリケーションで特によくある要件をまとめ、それぞれのニーズを満たすのに役立つ Auth0 の機能を説明します。

<div id="enterprise-providers">
  ## エンタープライズプロバイダー
</div>

ほとんどの企業は、全従業員の情報やユーザープロファイル情報を含む企業向けのアイデンティティリポジトリをすでに保有しています。そこには、パートナーや契約社員に関する情報が含まれていることもあります。そのため、B2E シナリオでよくある要件の 1 つは、そうしたユーザーが SAML2 プロバイダー、ADFS、Google Workspace、Azure AD、またはオンプレミスの企業向けディレクトリサービスなどの [Auth0 エンタープライズ接続](/docs/ja-jp/authenticate/identity-providers/enterprise-identity-providers) 経由でログインできるようにすることです。これは、ユーザーがアプリケーションごとに新たなユーザー名とパスワードを作成する必要がなく、代わりに同じログイン資格情報をすべてのエンタープライズ アプリケーションで使い回せるため、魅力的です。

これは特に、社内のセキュリティ部門にとって大きな利点があります。ユーザーの資格情報が各アプリケーションではなく、アイデンティティ基盤に対してのみ公開されるからです。さらに、このアーキテクチャではエンタープライズ アイデンティティプロバイダーが単一の停止ポイントとして機能するため、企業はアプリケーションへのアクセスを継続的に管理できます。ユーザーが組織を離れた場合、管理者は企業のアイデンティティプロバイダーでそのユーザーのアカウントを無効化するだけでよく、そのユーザーはそのアイデンティティプロバイダーを利用するどのアプリケーションにもログインできなくなります。

Auth0 を使えば、わずかな設定だけで、さまざまなエンタープライズプロバイダーによるログインを簡単に有効化できます。

<div id="groups-and-roles">
  ## グループとロール
</div>

ユーザー数が多い場合は、アクセス権限や特権を管理するために、グループやロールを設定できます。多くの場合、これらはディレクトリサービスに保存され、管理されます。

Auth0 では、認証時にディレクトリサービスまたはエンタープライズアイデンティティプロバイダーから、グループやロールなどのユーザー属性を取得できます。取得した属性は、アプリケーションに返されるトークンや、Auth0 <Tooltip tip="Management API: 顧客が管理タスクを実行できるようにする製品。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip> を通じて利用できるようにできます。

<div id="profile-translation">
  ## プロファイルの変換
</div>

ディレクトリやアイデンティティプロバイダーがある形式で属性を返しても、アプリケーションでは別の形式を使用している場合があります。Auth0 の [ルール](/docs/ja-jp/manage-users/user-accounts/metadata/manage-metadata-rules) を使うと、[ユーザープロファイル属性をマッピングして変換](https://auth0.com/rules/saml-attribute-mapping)できます。OIDC/OAuth、SAML、<Tooltip tip="Web Service Federation (WS-Fed): ドメインをまたいでユーザーアイデンティティを管理するためのプロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=WS-Fed">WS-Fed</Tooltip>、LDAP の間で変換することもできます。

たとえば、SAML IDプロバイダーから SAML アサーション形式の属性を取得するとします。ルールを使えば、その属性を OIDC/OAuth アプリケーションの <Tooltip tip="ID トークン: リソースへのアクセスではなく、クライアント自体のための認証情報です。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=ID+Token">ID トークン</Tooltip> のカスタムクレームに変換できます。

Auth0 Dashboard から、SAML 属性を Auth0 ユーザープロファイルにマッピングすることもできます。これを行うには、[Connections > Enterprise > SAMLP Identity Provider](https://manage.auth0.com/#/connections/enterprise) に移動し、SAML 接続を選択して、**Mappings** タブで属性マッピングを設定します。

<div id="extensibility-with-augmented-user-profiles">
  ## 拡張されたユーザープロファイルでの拡張
</div>

他のサービスから取得した属性やデータを使って、ユーザープロファイルを拡充したい場合があります。たとえば、住所や電話番号を受け取り、それを地理的な地域に変換したいことがあるでしょう。[Auth0 ルール](/docs/ja-jp/customize/rules) を使用すると、認証トランザクション中に実行される小さなコードスニペットを記述できます。これにより、ユーザー情報に対するロジックを実行したり、他のサービスを呼び出したりして、[user metadata](/docs/ja-jp/manage-users/user-accounts/metadata) を Auth0 ユーザープロファイルに追加し、必要に応じてアプリケーションに送信される生成済みのトークンにも追加できます。

<div id="single-sign-on">
  ## シングルサインオン
</div>

社内アプリケーションが複数ある場合は、それらの間で [シングルサインオン (SSO)](/docs/ja-jp/authenticate/single-sign-on) を設定することで、ユーザーは一度ログインするだけで済みます。

Auth0 は、業界標準のアイデンティティプロトコルを使って認証を外部化するアプリケーションとの連携をサポートしています。

* OIDC/OAuth
* SAML2
* WS-Fed

いくつかの設定を行うと、すべてのアプリケーションでエンタープライズアイデンティティプロバイダーを利用できるようになります。この構成では、Auth0 はアプリケーションとエンタープライズアイデンティティプロバイダーの間のブローカーとして機能します。

これにより、ユーザーが 1 つのアプリケーションにサインインすると、再度ログインしなくても Auth0 と連携している他のアプリケーションにアクセスできるようになります。これは、<Tooltip tip="シングルサインオン (SSO): ユーザーが 1 つのアプリケーションにログインした後、そのユーザーを他のアプリケーションにも自動的にログインさせるサービス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=SSO">SSO</Tooltip> セッションの有効期限が切れるまで有効です。セキュリティポリシーを満たすように、Auth0 で SSO セッションの長さを設定してください。

<div id="single-sign-on-integrations">
  ## SSO 連携
</div>

購入済みのアプリケーションを Auth0 と連携して、シングルサインオン (SSO) を有効にすることもできます。Auth0 では、次のようなアプリケーション向けに[あらかじめ用意された連携](/docs/ja-jp/customize/integrations/sso-integrations)を提供しています。

* Salesforce
* Zendesk
* Slack
* New Relic

<div id="branding">
  ## ブランディング
</div>

ブランディングは、あらゆるアプリケーションにおいて重要な要素です。ロゴ、色、スタイルは、アプリケーション全体で一貫している必要があります。Auth0 によって表示されるログイン、サインアップ、エラーページは、アプリケーションに合わせて[カスタマイズ](/docs/ja-jp/libraries/custom-signup)できます。独自のロゴ、テキスト、色を追加できます。グローバル展開に対応するための I18N/L10N サポートもあります。さらに、[確認用メールやパスワードリセット用メール](/docs/ja-jp/customize/email/email-templates)もカスタマイズ可能です。

[ログイン画面](/docs/ja-jp/libraries/lock/lock-ui-customization)は、アプリケーションのブランドに合ったドメイン名から提供されているように見える必要があります。一貫性を保つため、Auth0 によって表示されるログイン画面用に[カスタムドメイン](/docs/ja-jp/customize/custom-domains)を設定できます。

<div id="multi-factor-authentication">
  ## 多要素認証
</div>

社内向けまたは従業員向けのアプリケーションでは、機密性の高い情報を扱うことがよくあります。 [多要素認証 (MFA)](/docs/ja-jp/secure/multi-factor-authentication) は、データとアプリケーションの保護に役立ちます。Auth0 では、<Tooltip tip="多要素認証 (MFA): SMS で送信されるコードなど、ユーザー名とパスワードに加えて認証要素を使用するユーザー認証プロセス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=MFA">MFA</Tooltip> を実装するためのさまざまな方法を提供しています。さらに柔軟に運用するには、必要なアプリケーションやユーザーグループに対してのみ有効になるよう、ルールを使用できます。

<div id="logs-export">
  ## ログのエクスポート
</div>

ログを分析したり、長期間保存したりしたい場合は、Auth0 が提供する[ログを外部ツールにエクスポートする](/docs/ja-jp/deploy-monitor/logs)ための拡張機能を利用できます。分析や長期保存に役立ちます。Management API を使用してログデータを取得することもできます。

<div id="audit">
  ## 監査
</div>

企業ではログデータがさまざまな用途に使われており、その1つが監査レポートです。Auth0 はログファイルにさまざまなデータを記録しており、監査レポートの作成に役立つ場合があります。ログには、認証されたユーザー、使用されたアイデンティティプロバイダー、また <Tooltip tip="Auth0 Dashboard: サービスを設定するための Auth0 のメイン製品。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Auth0+dashboard">Auth0 Dashboard</Tooltip> で重要な管理上の変更が行われた日時に関する情報が含まれています。

各ログイベントにはイベントタイプがあります。Management API を使用してログデータを照会する際や、ログをログ分析ツールにエクスポートする際に、イベントタイプをフィルターとして使用できます。

<div id="monitoring">
  ## 監視
</div>

アプリケーションが依存するインフラストラクチャとサービスの監視は重要です。Auth0 では、購読可能な [Auth0 Status](https://status.auth0.com/) ページを提供しています。

Auth0 は障害の発生を最小限に抑えるようあらゆる努力をしていますが、サービスに何らかの中断が発生した場合は、ステータスページに表示されます。障害発生後の根本原因分析に関する文書化要件に対応するため、Auth0 は内部分析を実施し、分析の完了後にその結果を障害通知に掲載します。

<div id="attack-protection">
  ## 攻撃対策
</div>

現代のインターネットでは、残念ながらハッカーの存在を避けられません。ハッカーは常にアプリケーションへの侵入経路を探しています。たとえば、よく使われるパスワードでログインを試みたり、別の場所から盗まれた資格情報を使って、ユーザーが他のサイトでも同じパスワードを使い回していることを狙ったりします。

Auth0 の [攻撃対策](/docs/ja-jp/secure/attack-protection) は、Auth0 データベース接続に対するこうした状況を検出し、その際の対応方法を選べるようにします。<Tooltip tip="攻撃対策: Auth0 が攻撃を検出して軽減するために提供する機能。総当たり攻撃対策、不審な IP スロットリング、漏えいパスワードの検知、ボット検出、適応型多要素認証が含まれます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Attack+Protection">攻撃対策</Tooltip> を有効にし、対応オプションを設定して、このような事象が発生した場合に適切に対処できるようにしましょう。

<div id="github-deployment">
  ## Github デプロイ
</div>

アプリケーションコードの多くを Github で管理していますか？Auth0 の [Github Deployment extension](https://marketplace.auth0.com/integrations/github-actions) を使えば、Actions、ルール、フック、またはカスタムデータベースアクセス用のコードを、そこからデプロイできます。

CI/CD パイプライン全体を構築している場合は、より柔軟に利用できる [Auth0 Deploy CLI tool](https://github.com/auth0/auth0-deploy-cli) を使用してください。