OIDCベースのシングルサインオンに関する詳細情報
トラブルシューティング
バージョン9.6以降では、以前のappsettings.jsonにある設定は2つのファイルに保存されています:
- %PROGRAMDATA%\MemoQ Server\Oidc Backend\appsettings.User.jsonには、memoQ TMSのアップデートまたはアップグレード時に変更されないすべての設定が含まれます。
- %PROGRAMFILES%\Kilgray\MemoQ Server\Oidc\appsettings.jsonには、memoQ TMSのアップデートまたはアップグレード時にデフォルト値に戻る設定が含まれています。
このアップグレードは、バージョン9.5で使用したappsettings.jsonファイルには影響しません。Authentication Managerのサービスを再び開始するには、クリーンアップを行う必要があります:
- %PROGRAMDATA%\MemoQ Server\Oidc Backendフォルダ内のappsettings.jsonとappsettings.User.jsonファイルをテキストエディタで開きます。
- Serilogキーの下にある部分を除き、appsettings.jsonからappsettings.User.jsonまでのすべてをコピーします。
- ロギング設定を変更した場合は、Serilogキーの下の部分を%PROGRAMFILES%\Kilgray\MemoQ Server\Oidc\appsettings.jsonにコピーします。
- %PROGRAMDATA%\MemoQ Server\Oidc Backendフォルダからappsettings.jsonを削除します。
- memoQ TMS Deployment Toolまたはservices.mscWindows管理コンソールを使用して、MemoQ Server serviceを再起動します。
- MemoQ OIDC Backend Serviceを起動します。
この場合は、Authentication Managerのサービスを開始するだけで済みます。services.mscコマンドを実行し、リスト内のMemoQ OIDC Backend Serviceを右クリックして、メニューで開始をクリックします。
これを行うには、MemoQ.Security.Oidc.ConfigToolを使用して任意のコマンドを実行します。一番安全なのはGetBackendBaseUrlで、これは設定を何も変更しません。
管理者権限のあるコマンドプロンプトで、以下のコマンドを実行します:
cd "%PROGRAMFILES%\Kilgray\MemoQ Server\Oidc"
MemoQ.Security.Oidc.Backend.ConfigTool.exe GetBackendBaseUrl
コマンドプロンプトが戻ってきたら、データベースのアップグレードは完了です。
これは、.NET Frameworkの既知の問題によって発生します。%PROGRAMFILES%\Kilgray\MemoQ Server\Oidcフォルダ内のexeファイルは自己解凍形式のアーカイブです。その内容 (実際のプログラム) は、ユーザーの%TEMP%フォルダのサブフォルダに抽出され、そこから実行されます。何らかの原因 (たとえば、ウイルス対策ソフトウェア、.NETの更新など) によって%TEMP%フォルダがクリーンアップされ、Authentication Managerとその構成ツールが実行できなくなることがあります。
これを回避するには:マシンまたはシステムスコープで、DOTNET_BUNDLE_EXTRACT_BASE_DIRという名前の環境変数を作成します。値を%PROGRAMDATA%\Temp\.netに設定します。次に、Authentication Managerサービスを再度開始します:services.mscコマンドを実行し、リスト内のMemoQ OIDC Backend Serviceを右クリックして、メニューで開始をクリックします。
OIDCサインインに何か問題があった場合、memoQサポートに連絡する前に、このリストを確認してください。
-
%PROGRAMFILES%\Kilgray\MemoQ Server\Oidcフォルダー内にあるMemoQ.Security.Oidc.Backend.ConfigTool.exeを実行して、memoQ TMSのデータベース内の OIDC パートが最新バージョンであることを確認してください (ConfigTool を実行すると自動的に更新されます)。
-
MemoQ.Security.Oidc.Backend.ConfigTool.exeでGetIdProviderコマンドを実行して、構成されているIDプロバイダーを一覧表示します。この機能は、memoQwebのサインインページにOIDCボタンが表示されていない場合や、memoQデスクトップアプリで外部のIDプロバイダを使用するオプションが無効になっている場合に便利です。(少なくとも1つのIDプロバイダーが設定されていれば、このようなことは起こらないはずです。)
-
memoQwebのサインインページに問題がある場合は、MemoQ.Security.Oidc.Backend.ConfigTool.exeでGetMemoQWebBaseUrlsコマンドを実行します。memoQwebのベースURLが正しく設定されているかどうかを確認します。
-
Microsoft SQL Server Management StudioでmemoQ TMSのデータベースを開き、dbo.__EFMigrationsHistoryというテーブルがあるかどうかを確認します。ない場合は、データベースのOIDC部分をインストールする必要があります:MemoQ.Security.Oidc.Backend.ConfigTool.exeでGetMemoQWebBaseUrlsコマンドを実行します。これは、memoQwebから使用する際に、認証マネージャのCORS問題を回避するために必要です。そして、ここで説明されているように、OIDCを設定する必要があります。ここでは複数のベースURLを設定することができます。
-
memoQ TMSに設定されている OIDC ID プロバイダーを確認するには:https://<認証マネージャーのホスト名>:<認証マネージャーのポート>/auth/id_providers (例えば、https://memoq.mycompany.com:5001/auth/id_providers) をブラウザで開きます。memoQ TMSは、設定された ID プロバイダーの基本データを含む JSON を返します。
-
memoQ TMSのOIDCサインインの可能性を確認するには:https://< 認証マネージャのホスト名>:<認証マネージャのポート>/login (例えば、https://memoq.mycompany.com:5001/login) をブラウザで開きます。memoQ TMSはサインインページのOIDC部分を返します。
WindowsベースのSSOからOIDCベースの新ソリューションにユーザーを移行する
バージョン9.7からは、ユーザーがWindowsベースのSSOからOIDCベースのものにアカウントを移行することができます。これは、memoQ TMSのアカウントと同じ方法です:
-
ユーザーは、OIDCベースのアカウントでmemoQ TMSにサインインします。
-
聞かれたら、I worked on this server beforeオプションを選び、Windows ADのユーザー名とパスワードを入力します。
-
memoQ TMSは2つのアカウントをリンクし、その後、ユーザーは自分のOIDCアカウントでのみサインインできます。
OIDCプロバイダーに切り替えたユーザーは、以前の権限やグループメンバーシップを維持します。memoQ管理者がmemoQ TMSをWindows Active Directoryと同期させると、そのようなユーザーのグループメンバーシップが更新されます。
OIDCベースのSSOを設定しても、組織がWindowsベースのSSOを維持している場合は、ユーザーをWindowsベースのシステムに戻すこともできます。memoQまたはmemoQwebでその人のアカウントを削除してから、memoQ TMSを Windows Active Directory と同期させてください。そのアカウントはWindows ADユーザーとして再びユーザーリストに表示されます。
OIDCベースのユーザー認証の一般的なスキーマ
ユーザーの身元を承認する新しい方法は、Identity and Access Management (IAM) システムとしても知られる主要なIDプロバイダーによってサポートされているOpenID Connectプロトコルに基づいています。これらのスキーマは、memoQデスクトップアプリおよびmemoQwebでのユーザー認証フローを示しています。
- memoQでは、ユーザーは外部IDプロバイダー (Okta、Azure ADなど) でログインすることを選択します。
- memoQデスクトップアプリは、Authentication Managerのログインページ (IDプロバイダーを選択するため) のURLを要求して取得します。
- memoQデスクトップアプリは、ログインセッションを識別するためのランダムなログインIDを生成します。手順2で受け取ったログインURLをマシンのデフォルトブラウザーで開き、生成されたログインIDのハッシュをログインページに渡します。このページは、HTTPS経由でAuthentication Managerによって提供されます。
- ログインページで、ユーザーはIDプロバイダーを選択します。Authentication Managerのログイン機能により、ログインIDハッシュとIDプロバイダー名が渡されます。応答として、ログインIDハッシュとコールバックパスをパラメータとして使用して、IDプロバイダーのログインページへのリダイレクトを受信します。
- ブラウザーはIDプロバイダーにリダイレクトされ、ログインIDハッシュとコールバックパスがパラメータとして転送されます。
- IDプロバイダーはユーザーを認証し、認証コードを生成します。次に、ブラウザーをコールバックパスにリダイレクトし、生成された認証コードを渡します。
- ブラウザーはコールバックパスにリダイレクトされ、ログインIDハッシュと認証コードがパラメータとしてAuthentication Managerに転送されます。
- Authentication ManagerはIDプロバイダーを呼び出して、受信した認証コードをIDトークンと交換します。これは、より安全なバックチャネル通信によって行われます。
- Authentication Managerは、ユーザーの要求 (認証されたユーザーの詳細) を含む受信IDトークンを受信して検証し、そのIDトークンをレコードのキーとして使用してmemoQデータベースに保存します。
- memoQデスクトップアプリはログインIDをmemoQ TMSに送信し、memoQセッションを要求します。
- memoQ TMSはログインIDからハッシュを作成し、そのハッシュに基づいてIDトークンを取得しようとします。成功した場合は、IDトークンの認証ユーザー用のmemoQセッションが作成されます。
memoQwebからのログインフローは、デスクトップと同じロジックに従います:
- ユーザーはwebtransまたはwebPMで作業するためにmemoQweb (実質的には中央のウェブベースのログインモジュール) を開きます。ログイン画面には、従来のmemoQログインフォームの下に登録IDプロバイダーのリストが表示されます。
- ログインページで、ユーザーはIDプロバイダーを選択します。Webクライアントは、ログインセッションを識別するためのランダムなログインIDを生成します。
- ブラウザーはIDプロバイダーにリダイレクトされ、ログインIDハッシュとコールバックパスがパラメータとして転送されます。
- IDプロバイダーはユーザーを認証し、認証コードを生成します。次に、ブラウザーをコールバックパスにリダイレクトし、生成された認証コードを渡します。
- ブラウザーはコールバックパスにリダイレクトされ、ログインIDハッシュと認証コードがパラメータとしてAuthentication Managerに転送されます。
- Authentication ManagerはIDプロバイダーを呼び出して、受信した認証コードをIDトークンと交換します。これは、より安全なバックチャネル通信によって行われます。
- Authentication Managerは、ユーザーの要求 (認証されたユーザーの詳細) を含む受信IDトークンを受信して検証し、そのIDトークンをレコードのキーとして使用してmemoQデータベースに保存します。
- memoQwebフロントエンドはログインIDをmemoQ TMSに送信し、memoQセッションを要求します。
- memoQ TMSはログインIDからハッシュを作成し、そのハッシュに基づいてIDトークンを取得しようとします。成功した場合は、IDトークンの認証ユーザー用のmemoQセッションが作成されます。
memoQユーザーデータベース内のユーザーの識別
- ユーザーがユーザーデータベース内に見つかった場合、memoQの通常の許可フローが開始され、ユーザーはライセンスとアクセス権を取得します (つまり、ログインします)。
- ユーザーが見つからない場合は、これらのIDPクレデンシャルを使用して初めてログインしようとすることを意味します。ユーザーがこのmemoQ TMSで以前に作業したことがあるかどうかに応じて、Authentication Managerは新しいユーザーを作成するか、古いユーザーを更新します (詳細は後述します)。
テスト環境に関するヒント
SSOのセットアップを簡単にする方法は2つありますが、本番環境では使用しないでください。ただし、この機能を最初に試したときには、セットアップをより早く完了したい場合があります。
テスト環境では、商用の証明書の代わりに自己署名証明書を使用できます。
- CreateAndInstallSelfSignedCert.ps1PowerShellスクリプトファイルをダウンロードして展開し、管理モードで実行します。この手順では、自己署名証明書を作成し、信頼できる証明書として登録し、パスワードで保護された.pfxファイルに現在のフォルダにエクスポートします。
- コンピュータ証明書の管理アプリケーションを開き、証明書 - ローカルコンピュータ/個人/証明書および証明書 - ローカルコンピュータ/信頼されたルート証明機関/証明書ノードに、新しく作成された証明書が表示されます。
- appsettings.jsonファイルを編集し、Kestrel.Certificates.Default.Subjectプロパティを<dns name for the certificate>として以前使用していた値に設定します。
memoQデスクトップアプリまたはmemoQwebを使用するクライアントマシンごとに、証明書を信頼できるものとして登録する必要があります。
- サーバーマシン上で作成された証明書ファイルをクライアントマシンにコピーします。
- ファイルをダブルクリックすると、証明書のインポートウィザードが開きます。
- 現在のユーザーを保管場所として選択し、次へをクリックします。
- もう一度次へをクリックします。
- 証明書ファイルのパスワード (証明書をエクスポートするときに設定したパスワード) を入力し、次へをクリックします。
- もう一度次へをクリックします。
- 完了をクリックします。
サーバーマシン上でAuthentication Managerを自己署名証明書とともに使用する必要がある場合は、手順2から開始して、サーバーマシン上でもこれを行う必要があります。
テスト環境では、証明書ストアの代わりに証明書ファイルを使用できます。
Authentication Managerにこの証明書に対する読取りアクセス権を付与します。
- PFXファイルが格納されているフォルダを開きます。
- 証明書を右クリックします。コンテキストメニューでプロパティを選択します。
- <証明書> のプロパティウィンドウで、セキュリティタブをクリックし、編集ボタンをクリックします。
- <証明書> のアクセス許可ウィンドウで、追加ボタンをクリックします。
- ユーザーの選択...ウィンドウで、Authentication Managerサービスの名前を入力し (必要に応じて、services.mscを実行してすべてのサービスのリストを表示します)、Check namesボタンをクリックします。
- Windowsがサービス名を認識したら、OKボタンをクリックします。
- <証明書> 秘密キーのアクセス許可ウィンドウで、サービスの名前をクリックします。サービスに読み取り権限しかないことを確認し、OKボタンをクリックします。