> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-actions-triggers-prototype.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # ビジネスから従業員へ（B2E） > 既存のエンタープライズディレクトリサービスを拡張したい大規模組織でのB2Eのアーキテクチャシナリオについて説明します。 B2E（ビジネスから従業員へ）シナリオには、従業員ユーザーが使用するアプリケーションが含まれます。このアプリケーションは、個人的に使用するユーザーではなく、雇用主、大学、またはメンバーで構成されるグループなど、組織を代表して使用するユーザー向けです。組織によって独自に作成されたこのようなアプリケーションは、認証を外部化するためにOIDC/OAuthプロトコルを使用することがありますが、購入されたアプリケーションはSAMLプロトコルを使用することが多くあります。いずれの場合も、企業は通常エンタープライズユーザーの認証に、SAML IDプロバイダー、ADFS、Google Workspace、Azure AD、またはADやOpenLDAPなどのディレクトリサービス、もしくは多くはないもののカスタムDBなどの形式のエンタープライズ接続を使用することを希望します。 B2E環境用のアプリケーションを作成またはAuth0と統合している企業の場合、このシナリオに共通する要件がいくつかあります。このガイドでは、B2Eアプリケーションの最も一般的な要件をまとめ、それぞれのニーズを満たす上で役立つAuth0の機能について説明します。 ## エンタープライズプロバイダーほとんどの企業には、すべての従業員ユーザーとユーザープロファイル情報を含む企業IDリポジトリがすでにあります。これにはパートナーや請負業者に関する情報も含まれているかもしれません。したがって、B2Eシナリオの一般的な要件は、これらのユーザーがSAML2プロバイダー、ADFS、Google Workspace、Azure AD、またはオンプレミスの企業ディレクトリサービスなどの[Auth0エンタープライズ接続](https://auth0.com/docs/connections/identity-providers-enterprise)を介してログインできるようにすることです。これでアプリケーション毎にユーザー名とパスワードを作成する必要がなくなり、すべてのエンタープライズアプリケーションで同じログイン資格情報を利用できるため、ユーザーにとっての利便性が高まります。これは、ユーザーの資格情報が各アプリケーションではなくIDスタックにのみ公開されるため、社内のセキュリティを高める目的でも特に大きなメリットが見込めます。さらにこのアーキテクチャでは、エンタープライズIDプロバイダーが単一の遮断ポイントを提供するため、企業がアプリケーションへのアクセスを制御できます。ユーザーが退職などで組織を離れる場合、管理者が企業IDプロバイダーでユーザーのアカウントを無効にするだけで、ユーザーはそのIDプロバイダーを使用していずれのアプリケーションにもログインできなくなります。 Auth0を使用すると、いくつかの簡単な手順で設定するだけで、さまざまなエンタープライズプロバイダーを介したログインを有効にできます。 ## グループとロールユーザーが多い場合は、グループとロールを設定してアクセスと権限を管理できます。この情報は多くの場合、ディレクトリサービスに保存され、管理されます。 Auth0は、認証中にディレクトリサービスまたはエンタープライズIDプロバイダーから、グループやロールなどのユーザー属性を取得できます。その後、アプリケーションに返されるトークンまたはAuth0 Management APIを使用して、属性が利用できるようになります。 ## プロファイル変換ディレクトリやIDプロバイダーが属性を返す形式と、アプリケーションが使用する形式が異なることがあります。そこでAuth0の[ルール](https://auth0.com/docs/rules/current/metadata-in-rules)を使用すると、ユーザープロファイル属性を[マッピングおよび変換](https://auth0.com/rules/saml-attribute-mapping)できます。OIDC/OAuth、SAML、WS-Fed、およびLDAP間で変換することもできます。たとえば、SAML IDプロバイダーからSAMLアサーション形式で属性を取得します。ルールを使用すると、その属性をOIDC/OAuthアプリケーションのIDトークンのカスタムクレームに変換できます。ダッシュボードからSAML属性をAuth0ユーザープロファイルにマッピングすることも可能です。これを行うには、[［Connections（接続）］ > ［Enterprise（エンタープライズ）］ > ［SAMLP Identity Provider（SAMLP IDプロバイダー）］](https://manage.auth0.com/#/connections/enterprise)に移動し、SAML接続を選択して、**［Mappings（マッピング）］** タブで属性マッピングを設定します。 ## 拡張されたユーザープロファイルによる拡張性他のサービスから取得した属性やデータを活用して、ユーザープロファイルを強化することがあります。たとえば、住所や電話番号を受け取り、それを地理的な地域に変換したいような場合です。[Auth0ルール](https://auth0.com/docs/rules)を使用すると、認証トランザクション中に実行される小型のコードスニペットを作成できます。これにより、ユーザー情報を取得するためにロジックを実行したり、他のサービスを呼び出したりしてから、Auth0のユーザープロファイルに[ユーザーメタデータ](https://auth0.com/docs/users/concepts/overview-user-metadata)を追加し、必要に応じて結果のトークンをアプリケーションに送信できます。 ## シングルサインオン社内アプリケーションが複数ある場合は、それらに[シングルサインオン（SSO）](https://auth0.com/docs/sso)を設定して、ユーザーのログインが一度で済むように設定できます。 Auth0は、業界標準のIDプロトコルを使用して認証を外部化するアプリケーションとの統合をサポートしています。 * OIDC/OAuth * SAML2 * WS-Fed いくつか構成を行うと、すべてのアプリケーションでエンタープライズIDプロバイダーを活用できます。このセットアップでは、Auth0はアプリケーションとエンタープライズIDプロバイダーの間の仲介役を担います。ユーザーが1つのアプリケーションにサインインすると、再度ログインすることなく、Auth0と統合された他のアプリケーションにアクセスできます。この状態は、SSOセッションの有効期限が切れるまで継続します。セキュリティポリシーを満たすには、Auth0内でSSOセッションの長さを構成する必要があります。 ## シングルサインオンの統合購入したアプリケーションをAuth0と統合して、シングルサインオン（SSO）を実現することもできます。Auth0は、次のようなアプリケーション向けに、[事前構築された統合](https://auth0.com/docs/integrations/sso)を提供しています。 * Salesforce * Zendesk * Slack * New Relic ## ブランディングブランディングは、すべてのアプリケーションにとって重要です。ロゴ、色、スタイルは、アプリケーションのすべての画面で一貫している必要があります。Auth0によって表示されるログイン、サインアップ、エラーページをアプリケーションと一致するように[カスタマイズ](https://auth0.com/docs/libraries/custom-signup)しましょう。独自のロゴ、テキスト、色を追加できます。グローバル展開用のI18N/L10Nサポートもあります。[確認またはパスワードリセット用メール](https://auth0.com/docs/email/templates)もカスタマイズ可能です。 [ログイン画面](https://auth0.com/docs/libraries/lock/v11/ui-customization)は、アプリケーションのブランドドメイン名から送信されたことが分かるようにします。一貫性を維持するために、Auth0 によって表示されるログイン画面に[カスタムドメイン名](https://auth0.com/docs/custom-domains)を定義できます。 ## 多要素認証社内アプリケーションや従業員アプリケーションは、機密性の高いコンテンツを扱うことがよくあります。[多要素認証（MFA）](https://auth0.com/docs/mfa)は、データとアプリケーションの保護に役立ちます。Auth0は、MFAを実装するさまざまな方法を提供しています。さらに柔軟性を高めるために、ルールを使用して、必要なアプリケーションやユーザーグループに対してのみMFAを有効にすることができます。 ## ログのエクスポートログを分析したり、長期保存したりする必要がありますか？Auth0は、分析と保持のために[ログを外部ツールにエクスポート](https://auth0.com/docs/logs)するための拡張機能を提供しています。また、Management APIを使用してログデータを取得することもできます。 ## 監査企業ではログデータをさまざまな用途に使用しますが、その1つが監査レポートです。Auth0は、監査レポートに役立ちそうな、さまざまなデータをログファイルにキャプチャします。ログには、認証されたユーザー、使用されたIDプロバイダー、Auth0 Dashboardで重要な管理変更が行われた日時に関する情報が含まれています。ログイベントにはそれぞれイベントタイプがあります。Management APIを使用してログデータをクエリするとき、またはログをログ分析ツールにエクスポートするときに、イベントタイプをフィルターとして使用できます。 ## 監視アプリケーションが依存するインフラストラクチャとサービスを監視することは重要です。Auth0は、サブスクライブできる[Auth0ステータス](https://status.auth0.com/)ページを提供しています。 Auth0は停止を最小限に抑えるためにあらゆる努力をしていますが、サービスに中断が発生した場合は、ステータスページに表示されます。中断後の根本原因分析ドキュメントの要件をサポートするために、Auth0は内部分析を実施し、分析が完了すると中断通知で結果を公開します。 ## 攻撃防御インターネット上の現代の生活で注意すべきはハッカーの存在です。ハッカーは常にアプリケーションに侵入する方法を見つけようとしています。たとえば、一般的なパスワードを使用してログインしようとします。あるいは、ユーザーが他のサイトで同じパスワードを使い回すことを想定し、他の場所で盗んだ資格情報を使用する場合もあります。 Auth0の[攻撃防御](https://auth0.com/docs/anomaly-detection)は、Auth0データベース接続でこれらの状況を検出し、対応方法のオプションを提供します。攻撃防御を有効にして対応オプションを構成しておくと、このようなイベントが発生した場合に適切に対応できるようになります。 ## Githubデプロイメント Githubで多くのアプリケーションコードを管理していますか？Auth0の[Githubデプロイメント拡張機能](https://auth0.com/docs/extensions/github-deploy)を使用すると、そこからアクション、ルール、フック、またはカスタムデータベースアクセスのコードをデプロイできます。 CI/CD（継続的インテグレーション/継続的デプロイメント）の完全なパイプラインがある場合には、[Auth0 Deploy CLIツール](https://github.com/auth0/auth0-deploy-cli)を使用して柔軟性を向上させることができます。