SJP手法の使用に影響を与える可能性のある他の問題は何ですか?

LANSA RAMP-TS

SJP手法の使用に影響を与える可能性のある他の問題は何ですか?


主な問題の1つは、ユーザー・プロファイルとサイトのセキュリティ要件に関連します。

ユーザーが通常の5250画面を使用するときに、たとえばUSERAがSJPプログラムにアクセスできることが望ましくない場合があります。

さらに、USERAが自身のIBM i ジョブをプロファイルUSERA下で実行し、監査、ログ、およびセキュリティ情報に「実際」のユーザーが表示されるよう、多くのサイトから強く要求されています(ただし、多くの同時実行ユーザーに機能を提供するHTTP Webサーバーなどの「スレッド化された」プロセスがSystem iサーバーで次々に使用されるため、この情報は消失します)。

では、どのようにすれば、1つのユーザー・プロファイルUSERAでこのような世界の異なるビューをサポートできるのでしょうか?

·         実際の5250セッションにサイン・オンした場合、通常のサインオンメニューが表示されます。

·         RAMPスクリプト経由でサイン・オンした場合、SJPプログラムがメインの「メニュー」として表示されますか?

この問題にはいくつかの解決策があります。

·         RAMPスクリプト経由でログインする場合、IBM i サイン・オン画面のプログラム/プロシージャーオプションを使用してSJPプログラムを指定します。SJPにセキュリティ・ロジックを追加して、ユーザーが実際の5250インターフェースを使用して同じ操作を行えないようにすることができます(ポイント2を参照)。

·         共通のメニュー・プログラムを使用する場合、自身がRAMPスクリプトから呼び出されていることを検出してからSJPプログラムを呼び出すよう、そのプログラムを変更できます。同様に、初めに共通メニューを表示し、「非表示」の特別メニュー・オプションを使用してSJPプログラムを呼び出すこともできます。SJPプログラムは、たとえば実際の人間のユーザーには実行不可能なRAMPスクリプトとの暗号化交換を実行して、自身がRAMPスクリプトからアクセスされていることを確認できます。

·         RAMPスクリプトは、初期プログラムとしてSJPプログラムが指定された、汎用の"USERX"として初期サイン・オンできます。SJPプログラムは画面を表示して実際のユーザー・プロファイルとパスワードを要求します。RAMPログオン・スクリプトはこれを埋め込んで戻します。次にIBM APIを呼び出して、現在のジョブのユーザー・プロファイルを汎用のUSERXから実際のユーザーに変更します。再度、実際のユーザーには実行不可能な暗号化交換を使用して、RAMPスクリプトからのアクセスであることを確認できます。