エンドユーザー認証
このセクションは、エンドユーザー（OutSystemsアプリケーションのユーザー）の認証にのみ適用されます。
開発者やIT管理者などのITユーザーの認証については、LifeTimeで構成します。
新しいモジュールの開発を開始する際には、エンドユーザー認証のためのビルトインロジックが用意されています。OutSystemsには、Internal、Active Directory、LDAP（Lightweight Directory Access Protocol）、SAML 2.0（Security Assertion Markup Language）、Azure AD（Azure Active Directory）、OKTAという6つの異なる認証方式があります。
- Internal
- デフォルトの認証方式です。エンドユーザーの情報は、OutSystemsのデータベースに保存されます。資格情報は保存されませんが、資格情報を基にした暗号のハッシュ関数を計算し、その結果のみが保存されます。エンドユーザーがログインを試行すると、ハッシュ関数を再計算し、その結果をデータベースの値と比較します。
- Active Directory
- Active Directoryを使用してエンドユーザーを認証します。オンプレミスインストールでのみ利用可能です。
Active Directory認証の構成方法をご覧ください。 - LDAP
- Active Directory向けに構成したLDAPまたは標準的なLDAPを使用して、LDAPサーバーと照合してエンドユーザーを認証します。
LDAP認証の構成方法.をご覧ください。 - SAML 2.0
- SAMLベースの認証を使用して、商用IDプロバイダ（OneLogin、PingFederateなど）から提供されるシングルサインオン（SSO）でエンドユーザーを認証します。
SAML 2.0認証の構成方法をご覧ください。 - Azure AD:
- SAMLベースの認証を使用して、Azure AD IDプロバイダから提供されるシングルサインオン（SSO）でエンドユーザーを認証します。
Azure AD認証の構成方法をご覧ください。 - OKTA
- SAMLベースの認証を使用して、OKTAから提供されるシングルサインオン（SSO）でエンドユーザーを認証します。
OKTA認証の構成方法をご覧ください。
注記:
Active Directory、LDAP、SAML 2.0、Azure ADまたはOKTAを使用してユーザーを認証する場合、ユーザーを手動で作成する必要はありません。最初のログイン時にOutSystemsデータベース内に自動的に作成されますが、パスワードデータは保存されません。
- Active Directory認証またはLDAP認証を使用する場合、OutSystemsデータベース内にユーザーが存在し、ユーザーのパスワードが定義されてるときは、Usersモジュールは最初にローカルでユーザー認証を試みます。SAML 2.0、Azure AD、OKTAの各認証方式を使用する場合、この最初の認証は試行されません。
エンドユーザーの認証を構成する
エンドユーザー認証を構成するには、以下の手順を実行します。
-
Usersアプリケーションで、サイドバーにある［Configure Authentication］をクリックします。
-
［Authentication］ドロップダウンリストから認証方式を1つ選択します
Internal Only、Active Directory、LDAP、Azure AD、SAML 2.0、またはOKTA。
-
前の手順で［Active Directory］、［LDAP］、［SAML 2.0］、［Azure AD］または［OKTA］を選択した場合は、手順2で選択した認証方式に固有のその他の構成フィールドを入力する必要があります。これらの認証方式の構成の詳細については、このセクションの他のトピックをご覧ください。
認証フロー
エンドユーザーが初めてアプリケーションを使用し、認証済みエンドユーザーのみに表示を許可する画面にアクセスした場合、セキュリティ例外が発生します。OutSystemsでは、以下の処理が実行されます。
-
SAML 2.0、Azure AD、またはOKTA認証を使用するようにプラットフォームが構成されている場合、エンドユーザーは、エンタープライズの資格情報（ユーザー名およびパスワード）を入力する必要があるWebページにリダイレクトされます。認証が成功すると、エンドユーザーはOutSystemsアプリケーションにリダイレクトされます。
-
プラットフォームが統合Windows認証を使用するように構成されていて、かつエンドユーザーがPlatform Serverと同じドメイン内にいる場合、エンドユーザーは統合Windows認証を使用して認証されます。
エンドユーザーがリクエストを行うと、サーバーはHTTP 401ステータスを返し、認証が必要であることをエンドユーザーのブラウザに通知します。すでにエンドユーザーの資格情報がブラウザに保存されている場合、資格情報をWebサーバーに自動的に送信します。保存されていない場合は、資格情報の入力フォームがブラウザに表示され、入力内容をサーバーに送信します。つまり、カスタムログインページがある場合でも、エンドユーザーには表示されません。
-
プラットフォームが統合Windows認証を使用するように構成されていない場合、エンドユーザーはログイン画面にリダイレクトされます。エンドユーザーが資格情報を送信すると、以下の処理が実行されます。
-
OutSystemsのデータベースと照合して資格情報を検証します。
-
プラットフォームがActive Directory認証またはLDAP認証を使用するように構成されているかを確認し、以下のいずれかを実行します。
A) プラットフォームがActive Directoryを使用して認証するように構成されている場合、構成済みのドメインサーバーと照合して資格情報を検証します。
B) プラットフォームがLDAPを使用して認証するように構成されている場合、構成済みのLDAPサーバーと照合して資格情報を検証します。
-
-
これまでのプロセスでエンドユーザーが認証できない場合、「Invalid Login」というメッセージがエンドユーザーに表示されます。
ユーザーデータの同期
Active Directory、LDAP、SAML 2.0、Azure ADまたはOKTAによるエンドユーザー認証が1回または複数回実行されると、OutSystemsデータベース内のユーザーデータが外部認証システムからの最新のデータで更新されます。更新される各ユーザーのアトリビュートは以下のとおりです。
- Name
- Mobile Phone
この同期は構成されている認証に応じて、以下のタイミングで実行されます。
- ログイン成功後
- ログインしたユーザーのデータが更新されます。Active Directory、LDAP、SAML 2.0、Azure AD、またはOKTA認証を使用する場合に実行されます。
- 日次タイマー設定時
- OutSystemsデータベース内の外部認証ソースのすべての既存ユーザーのデータが更新されます。対象となるユーザーは、ユーザー名に
\（スラッシュ）文字が含まれるユーザーです。
タイマーは「SynchronizeDomainUsers」という名前で、Usersモジュールで構成します。このタイマーに基づく同期は、Active Directoryを使用している場合にのみ実行されます。
ただし、このプロセスによってOutSystemsデータベース内に新しいユーザーが作成されることはありません。
このセクションの記事
- Active Directory認証の構成
- アプリケーションのActive Directoryエンドユーザー認証を構成する方法を説明しています。
- LDAP認証を構成する
- アプリケーションのLDAPエンドユーザー認証（Active Directoryを使用したLDAPと標準的なLDAPの両方）を構成する方法を説明しています。
- SAML 2.0認証を構成する
- アプリケーションのSAML 2.0エンドユーザー認証を構成する方法について説明しています。
- Azure AD認証を構成する
- アプリケーションのAzure ADエンドユーザー認証を構成する方法について説明しています。
- OKTA 認証を構成する
- アプリケーションのOKTAエンドユーザー認証を構成する方法について説明しています。
- 統合認証
- OutSystemsでの統合Windows認証について詳細に説明しています。
- 永続的ログイン
- エンドユーザーが一度ログインに成功すると次回以降はログインが不要になる、永続的ログインについて詳細に説明しています。
- シングルサインオン
- シングルサインオン、およびエンドユーザーをすべてのアプリケーションで一度に認証する方法について詳細に説明しています。