用語集

    A
  • Authenticator保証レベル。認証プロセスの強度をランク付けするための業界標準の分類。AAL1(低い)、AAL2(高い)、AAL3(非常に高い)の3つのレベルがあります。
  • アサーションコンシューマーサービスのURL。多くの場合、サービスプロバイダー(SP)のサインインURLと呼ばれます。これは、SAMLレスポンスが投稿されるエンドポイントであり、SPによってIDプロバイダーに提供される必要があります。
  • Microsoft Windowsドメインネットワーク用のオンプレミスユーザーアカウント管理サービス。
  • Okta管理者。管理者は、Okta管理者ダッシュボードにアクセスできます。このダッシュボードでは、エンドユーザーアカウントのプロビジョニングとデプロビジョニング、およびエンドユーザーエクスペリエンス全体の他の多くの側面を構成および維持します。
  • Agentless Desktop Single Sign On。この機能を有効にすると、ユーザーがWindowsネットワークにサインインするとき、Oktaによって自動的に認証されます。ユーザーは1回サインインするだけでよく、Oktaを介してアクセスするアプリケーションごとに個別の資格情報を使用する必要がありません。
  • Okta内の複数orgの周囲の管理レイヤー。Aerialアカウントはorgの外部に存在し、Aerialアカウントにリンクされた任意の本番またはプレビューorgを管理できます。
  • Aerialアカウントの任意のorg内のすべてのAerial APIアクションの認証サーバーを保持するorg。Aerial orgとして永続的に機能する1つのorgを選択します。スーパー管理者は、Aerial org内にAPIクライアントを作成してAerialアカウントにアクセスできます。Aerial orgには、Okta Aerialアクションに関連付けられたすべてのSystem Logイベントも含まれます。
  • Oktaの外部でサービスとして実行される軽量のソフトウェアプログラム。エージェントは通常、ファイアウォールの背後にインストールされ、OktaがオンプレミスサービスとOktaクラウドサービス間で通信できるようにします。
  • アプリケーションOktaの目的では、アプリはユーザー認証を必要とする特定のタスクをいくつでも提供するWebベースのサービスです。
  • Webサイトまたはサービスへのアクセスを要求するエンティティのIDを確認するサインインプロセス。エンティティには、個人またはAPIリクエストなどの自動ユーザーエージェントが含まれる場合があります。
  • AWSクラウド環境のすべてのインフラストラクチャリソースを記述およびプロビジョニングするための共通言語を提供します。CloudFormationを使用すると、管理者は単純なテキストファイルを使用して、すべてのリージョンとアカウントのアプリケーションに必要なすべてのリソースを安全にモデル化およびプロビジョニングできます。
  • B
  • SAMLを有効にすると、ユーザーと管理者は、ユーザー名とパスワードを使用してサービスプロバイダーのサインインページにサインインできなくなります。ユーザーのすべてのサインインは、IDプロバイダーを経由して行われます。ほとんどの場合、サービスプロバイダーには、ユーザー名またはパスワードを使用してサインインする必要がある場合に使用するバックドアURLがあります。
  • C
  • 認証局。公開鍵の所有権を確認するデジタル証明書の発行者。
  • カスタマーアイデンティティーアクセス管理。CIAMはソフトウェアソリューションであり、Organizationは、アプリケーションへのカスタマーアクセスを制御し、データベース、オンラインプロファイル、およびその他の利用可能な情報とリンクすることによりカスタマーアイデンティティーを特定し、カスタマープロファイル情報を安全に取得して管理できるようになります。
  • OAuth2セキュリティトークンに含まれるサブジェクト(ユーザー)に関するステートメント。クレームは、たとえば、名前、ID、キー、グループ、または特権に関するものです。セキュリティトークンのクレームは、トークンの種類・ユーザーの認証に使用される資格情報の種類・アプリケーションの構成によって異なります。
  • Oktaサービスと相互作用するもの。従来のクライアントサーバーモデルでは、Oktaがサーバーです。クライアントは、エージェント、Okta Mobileアプリ、またはブラウザープラグインである可能性があります。
  • 総称して「クラウド」と呼ばれる世界中のデータセンターからインターネットを介して提供されるアプリケーションとサービス。
  • 単一の目的で一緒に使用される、特定のインフラストラクチャ内のコンピュータインスタンス(物理または仮想)のグループ。
  • Oktaコミュニティによって作成されたが、Oktaによってテストおよび検証されていないアプリのためのカテゴリです。
  • Oktaコミュニティによって作成され、アクティブな使用や複数のユーザーなど、品質または信頼性の証拠を示したアプリのカテゴリ。ただし、Oktaはそれをテストしておらず、サポートしていません。
  • ユーザーがOktaに対して認証した後にユーザーセッションを継続的にモニタリングするIdentity Threat Protection機能。認証およびグローバルセッションポリシーを評価してセッションコンテキストの変化を識別します。
  • 証明書失効リスト。有効期限が切れる前に取り消された、または無効とマークされたデジタル証明書のインデックス。CRLのデジタル証明書は信頼するべきではありません。
  • Okta Universal Directory内のユーザーを管理するためにOktaで使用される一般的なデータベース操作である、作成・参照・更新・非アクティブ化(Oktaの場合、削除ではない)。
  • D
  • ユーザーがアプリケーションの一部に直接アクセスできるようにします。この機能がサポートされている場合、ユーザーはディープリンクにナビゲーションし、SPから開始されたSAML SSOを使用して、アプリケーションに対して認証を行えます。認証後、ユーザーはホームページではなくSPの特定のページにリダイレクトされます。
  • アクティブにサポートされなくなった機能のライフサイクル状態。廃止の機能をorgに割り当てることはできません。
  • ユーザーアカウントをOkta Verifyに追加するプロセス。
  • デバイス上でOkta Verifyのアプリインスタンスにユーザーをバインドするプロセス。
  • Okta organizationの属性。Oktaは完全修飾ドメイン名を使用します。つまり、常にトップレベルドメイン(.com、.euなど)が含まれますが、プロトコル(https)は含まれません。
  • ネットワークトラフィックの方向を示します。たとえば、Okta Universal Directoryでユーザーアカウントが作成された後、アカウント情報とそれ以降の更新がターゲットアプリケーションにプッシュダウンされます。
  • Oktaからデータを受信するアプリケーション。
  • E
  • OktaサポートにOrgの有効化を依頼することでOrgをテストできる、オプトイン機能。スーパー管理者は、Okta Admin Consoleで選択したEA機能を有効または無効にすることもできます。
  • 管理制御を持たないorg内の人々。マイアプリケーションホームページのアイコンからアプリに認証できますが、アカウントは管理者によって管理されます。
  • サポート終了。EOL機能はOkta Admin Consoleでは使用できなくなりました。
  • F
  • 明確な機能性。機能は製品内にバンドルされますが、たとえば早期アクセス機能のように個別に提供される場合もあります。
  • 連邦情報処理標準。暗号化モジュールのベンチマークおよび認定プログラム。
  • ユーザーがアプリにアクセスしようとするときにIDプロバイダーを介して再認証する必要がある管理オプション。アクティブなセッションがある場合でも、ユーザーは再認証する必要があります。
  • 完全修飾ドメイン名。転送プロトコル(http / https)を含むインターネットサイトの完全なURL。
  • G
  • 各顧客のSKUに応じてすべてのorgで利用できる機能について説明します。
  • ユーザーのカテゴリ。グループを使用すると、管理者はアプリを多数のエンドユーザーに簡単に割り当てることができます。
  • I
  • IDおよびアクセス管理。ソフトウェアシステム内のユーザーとグループだけでなく、それぞれがアクセスできるリソースと実行できる機能も体系的にまとめるプロセス。IAMは、認証・承認・アクセスコントロールに対処します。
  • サインインページに[Username(ユーザー名)]フィールドのみを表示する認証方法。Oktaは、identifier first認証を使用して、サインインを完了するために使用するIDプロバイダーを決定します。
  • IDプロバイダーの略で、ユーザー・アカウントを管理するサービスです。IdPはサービス・プロバイダーにSAMLレスポンスを送信し、シングルサインオン用にエンドユーザーを認証します。
  • IDプロバイダー(IdP)により開始されたSAML認証。このフローでは、IdPはサービスプロバイダーにリダイレクトされるSAMLレスポンスを開始し、ユーザーのIDをアサートします。Oktaでは、ユーザーがSAMLアプリケーションのアプリアイコンをクリックした後にプロセスがトリガーされます。
  • IDプロバイダーで開始されたシングルサインオン。IdPセキュリティ・ドメインから開始されたシングルサインオン操作を意味します。IdPフェデレーションサーバーはフェデレーションSSO応答を作成し、応答メッセージとオプションの動作状態を使用してユーザーをSPにリダイレクトします。
  • 外部IDプロバイダーのユーザーがOktaへのシングルサインオン(SSO)できるようにします。
  • orgからアプリにアクセスしてOkta Verifyにユーザーアカウントを追加するプロセス。
  • 物理マシンまたは仮想マシンでホストされているソフトウェアアプライアンスまたはその他のリソースの発生。
  • 独立系ソフトウェアベンダー。Oktaは、さまざまなISV(通常はエンタープライズアプリケーションを作成するISV)と提携して、オンプレミス、クラウド、またはネイティブからモバイルへのデバイスをOktaと統合します。
  • Integrated Windows Authenticationを使用すると、ユーザーがWindowsネットワークにサインインするときは常に、OktaおよびOktaを介してアクセスされるアプリによってユーザーが自動的に認証されます。Oktaでは新しいIWA機能を追加することはせず、限定的なサポートとバグ修正のみを提供します。
  • J
  • ジャストインタイムプロビジョニング。ユーザーが初めてサインインしたときにユーザーのアカウントを作成するSAMLベースの方法。JITのバリエーションは、事前に作成されてOktaにインポートされたユーザーを変更できます。これらのシナリオでは、ステージング状態または非アクティブ化状態のユーザーは、最初にサインインしたときにアクティブ化されます。
  • K
  • ノードが安全でないネットワーク上でIDを安全に証明できるようにするコンピュータネットワーク認証プロトコル。
  • L
  • ライトウェイトディレクトリアクセスプロトコルX.500ベースのディレクトリサービスにアクセスするために使用される軽量のクライアントサーバープロトコル。LDAPは、伝送制御プロトコル/インターネットプロトコル(TCP / IP)またはその他のコネクション型転送サービスで実行されます。
  • ユーザーは、次のいずれかの方法でOktaのデバイスレコードにリンクされます。(1)ユーザーがデバイスからOktaセッションを確立し、セッション中にOktaにデバイスIDを提供する場合。(2)Okta APIを介して。
  • M
  • アプリケーション管理モバイルビジネスアプリへのアクセスを制御するソフトウェアとサービス。MAMは、会社および個人のデバイスで動作します。
  • 選択したデバイス管理ソリューションによって制御され、[Security(セキュリティ)]>[Device integrations(デバイス統合)]でデバイス管理用に構成され、Okta Verifyに登録されたデバイス。
  • 多要素認証。エンドユーザーがアプリケーションにサインインする際の本人確認に使用する追加のセキュリティレイヤー。
  • 相互トランスポートレイヤーセキュリティ。双方向認証を保証する暗号化プロトコル。
  • ユーザーのアプリケーションを表示するOktaホームページ(orgname.okta.com/app/UserHome)。
  • N
  • 逆プロキシ、ロードバランサー、メールプロキシ、HTTPキャッシュとして使用可能なWebサーバー。
  • トラフィックが単一のネットワーク接続を飽和させないようにするための、結合された仮想ポートへの2つのイーサネットポートの組み合わせ。
  • Okta Verifyに登録されているが、選択したデバイス管理ソリューションの非管理対象であるか、[Security(セキュリティ)]>[Device integrations(デバイス統合)]でデバイス管理用に構成されていないデバイス。
  • O
  • Okta Access Gateway。SAMLまたはOIDCをネイティブにサポートしないWebアプリケーションを保護するように設計された、リバースプロキシベースの仮想アプリケーション。Okta Access Gatewayは、HTTPヘッダーとKerberosトークンを使用してレガシーアプリケーションと統合し、URLベースの承認などを提供します。
  • OpenIDコネクターOAuth 2.0(承認フレームワーク)上の認証レイヤー。OIDC標準は、OpenID Foundationによって制御されています。
  • Okta Integration Network。何千もの事前統合されたビジネスおよびコンシューマーアプリケーションで構成されるオンデマンドサービス。
  • Windows、iOS、Android、MacOS上のOktaのSAML、WS-Fed、OIDCアプリに対するパスワードなしの認証。
  • Oktaの完全に機能するバージョンへの完全なアクセスを提供するサンドボックス環境。oktapreview orgを使用すると、機能をユーザーにプッシュする前にテストできます。
  • Okta検証済み。Okta Integration Networkでは、このステータスは、統合がOktaによって構築、テスト、および検証されたか、パートナーによって構築されてからOktaによってテストおよび検証されたことを意味します。
  • Okta Mobility Management。管理者がユーザーのモバイルデバイス上の仕事関連のアプリケーションとデータを管理できるようにするサービス。管理対象アプリをダウンロードするには、ユーザーはサービスに登録する必要があります。
  • Linux(CentOSまたはRHEL)あるいはWindows(x86/x64)サーバーで実行され、ファイアウォールの内側に配置される軽量エージェント。オンプレミスプロビジョニングエージェントは、Oktaからプロビジョニング命令を取得し、SCIMメッセージを適切なSCIMエンドポイントまたはコネクタに送信します。
  • 帯域外。2つのエンドポイント間のプライマリ通信とは異なる方法を使用して2つのエンドポイント間で送信される信号。Okta Verifyを参照する場合、帯域外はサインインURLを使用した手動デバイス登録を参照します。
  • 実際のOrganizationを表すOktaコンテナ。
  • ワンタイムパスワード。多要素認証の一種で、エンドユーザーは、テキストメッセージや通話、またはGoogle AuthenticatorなどのAuthenticatorアプリを通じてシークレットコードを受け取ります。ユーザーは、サインイン時にパスワードに加えてこのコードを入力します。
  • 組織単位ユーザー、グループ、コンピューター、またはその他の組織単位用のActive Directoryコンテナー。OUは、グループポリシー設定を割り当てたり、管理権限を委任したりできる最小の単位です。
  • P
  • プロビジョニング統合のためのパートナー構築EA機能ステータスは廃止されました。この機能ステータスを持つすべてのプロビジョニング統合は、Okta検証済み機能ステータスに変更されます。
  • この用語は廃止されました。「Okta検証済み」を参照してください。
  • 公開鍵基盤。デジタル証明書と証明書チェーンを作成・維持するために使用される一連のツールとポリシー。
  • 所有証明。キーペアの所有者が公開鍵に関連付けられた秘密鍵を実際に持っていることを保証する検証プロセス。
  • Oktaが決定した機能セット。
  • プロファイルソースは、ユーザープロファイル属性の真実性のソースとして機能するアプリケーションです。ユーザーは、一度に1つのアプリケーションまたはディレクトリでのみソースにできます。
  • ユーザーオブジェクト属性とそのライフサイクル状態のフローとメンテナンスを定義する参照/インポートメソッド。Oktaユーザーのプロファイルがアプリケーションまたはディレクトリによってソースされている場合、Oktaプロファイルの属性とライフサイクル状態はそのリソースから排他的に取得されます。プロファイルはOktaで編集できません。
  • ユーザーが必要とするソフトウェアとサービスへのアクセスを許可する企業全体のプロセス、およびそれらのリソースの構成・展開・管理。
  • R
  • ユーザーがOkta Verifyにバインドされるデバイス。各登録済みデバイスはOkta Universal Directoryにおける一意のオブジェクトです。
  • 証明書利用者識別子。証明書利用者はIdPからSAMLアサーションを受信します。
  • S
  • セキュリティアサーションマークアップ言語。IDプロバイダーとサービスプロバイダーとの間でデータを交換することによってIDを確認し、認証を提供するオープンスタンダード。
  • Simple Certificate Enrollment Protocol。URLを介してデバイスにデジタル証明書を発行するための自動登録プロセス。
  • OktaがOktaユーザープロファイルに追加できるアプリプロファイルの属性を識別するプロセス。
  • System for Cross-domain Identity Management。ユーザープロビジョニングの自動化を可能にするオープンスタンダード。SCIMは、IDプロバイダー(複数の個別ユーザーを持つ企業など)とサービスプロバイダー(エンタープライズSaaSアプリなど)の間でユーザーIDデータを通信します。
  • プロビジョニングエージェントによって送信されたSCIMメッセージを処理できるエンドポイント。このエンドポイントは、SCIMをネイティブにサポートするアプリケーション、またはプロビジョニングエージェントとオンプレミスアプリケーションの間の仲介役として機能するSCIMコネクタにすることができます。
  • リソースにアクセスしたいというクライアントによる指示。
  • エンドユーザーがQRコードをスキャンせずにモバイルデバイスをOkta Verifyに登録できるようにする、Oktaで生成された文字列。
  • Okta Sign-In Widgetは、Webおよびモバイルアプリケーションのユーザーを認証するために使用できる、完全な機能を備えたカスタマイズ可能なサインインエクスペリエンスを提供するJavascriptウィジェットです。
  • 一連のユーザー資格情報を使用してアプリに安全にアクセスします。同義語には、(シングルサインオンやサインオンポリシーなどの)サインオンやログインなどがあります。
  • SAMLサービスプロバイダーがIDプロバイダーにログアウト要求を送信し、IDプロバイダーとサービスプロバイダーの現在のセッションの両方を閉じるログアウト方法。Oktaは、SP起点ログアウトのみをサポートします。
  • VMWare、VMWare vSphere、AWS、または同様のシステムで実行される構成可能なアプライアンス。Okta Access Gatewayは、クライアントインフラストラクチャ用に構成できる、事前構成されたダウンロード可能なVMイメージです。
  • ユーザーオブジェクト属性のフローとメンテナンスを定義するプロセス。ソーシングは、フルプロファイルレベルまたは属性レベルで適用できます。Oktaソースとは、Oktaプロファイルで行われた編集が、関連するすべてのアプリケーションに流れることを意味します。アプリソースとは、ユーザーのアプリケーションプロファイル(Active Directoryなど)で行われた編集がOktaプロファイルに流れることを意味します。
  • サービスプロバイダー。Oktaでは、サービスプロバイダーは、ユーザーにサインインする方法としてSAMLレスポンスを受け入れる任意のWebサイトです。サービスプロバイダーは、ユーザーをIDプロバイダー(Okta)にリダイレクトして、認証プロセスを開始します。
  • サービス・プロバイダーで開始されたシングルサインオン。サービスプロバイダー(SP)によって開始されるSAML認証。これは、エンドユーザーがサービスプロバイダーのリソースにアクセスを試みたか、サービスプロバイダーに直接サインインしたときにトリガーされます。
  • Shared Signals Framework。orgがサードパーティのセキュリティプロバイダーからリスクシグナルを受信できるようにするIdentity Threat Protection機能。
  • シングルサインオン。SSOプラットフォームでは、ユーザーは1つの名前とパスワードを入力して、複数のアプリケーションにアクセスできます。Oktaは、ファイアウォールの背後とクラウドの両方のアプリケーションに対して、PC、ラップトップ、タブレット、およびスマートフォン間でシームレスなSSOエクスペリエンスを提供します。
  • セルフサービスによるパスワードのリセット。ユーザーが管理者やヘルプデスク担当者の助けを借りることなしに自分のパスワードをリセットできるようにする機能。この機能は、パスワードポリシーまたはOktaアカウント管理ポリシーで構成できます。
  • セルフサービス登録。org内のユーザーが自分のアカウントを作成できるようにするプロセス。Identity Engineでは、これはプロファイル登録ポリシーを使用して実現できます。
  • Secure Web Authentication。SAMLまたは独自のフェデレーションサインイン方式をサポートしないアプリ用にOktaによって開発されたSSO統合方式。ユーザーがOktaホームページからSWAアプリにアクセスすると、Oktaは保存された暗号化された資格情報をアプリのサインインページに投稿します。
  • T
  • 時間ベースのワンタイムパスワード。TOTPは、秘密鍵と現在の時刻から一意のコードが生成される多要素認証の一種です。コードがユーザーに送信され、ユーザーはユーザー名とパスワードとともにコードをサインインフォームに入力します。また、コードは(TOTPジェネレーターの構成方法に応じて)30秒または60秒後に期限切れになり、使用できなくなります。
  • Trusted Platform Module。ほとんどのデスクトップおよびモバイルデバイスに組み込まれているマイクロチップ。主に暗号化鍵を含む、改ざん防止のセキュリティ機能を提供するために設計されています。
  • U
  • 無制限の数のユーザーとすべてのタイプの属性を格納するOktaユーザーディレクトリ。Okta Integration Networkのすべてのアプリケーションは、LDAPまたはAPIを使用してOkta Universal Directoryにアクセスできます。
  • IDベースの脅威に対応してサポート対象アプリのユーザーセッションを終了するIdentity Threat Protection機能。
  • ディレクトリまたはアプリからOktaへのネットワークトラフィック。
  • Oktaにデータを提供するプロビジョニングアプリケーション。
  • Uniform Resource Identifier。Webページ、ブック、ドキュメントなどの特定のリソースを識別するために使用される一意の文字シーケンス。URLとは異なり、場所情報(https://)は含まれません。
  • アクセスをリクエストしている人物の資格情報(知っていること、持っているもの、あなたであること)を、以前に証明され、Oktaに保存され、要求しているIDに関連付けられているものと比較することによって、要求しているIDが正しいことを確認する、または否定するプロセス。Oktaでは、ユーザー検証は、FIDO2(WebAuthn)AuthenticatorやOkta FastPassを使用する場合など、ユーザーが生体認証またはセキュリティキー検証を求められる場合も指します。(米国商務省国立標準技術研究所より部分的に採用された用語)