Clever Geek Handbook

SAP Netweaver AS Javaでの認証の構成（パート2/3）

エントリー



シリーズの最初の部分 「SAP Netweaver AS Javaでの認証の構成」では、SAP NW AS Javaソフトウェアプラットフォームで実行されるアプリケーションで認証を構成するためのさまざまなアプローチについて説明しました。 また、認証設定を実行するためのさまざまなプロジェクトチーム（開発者、機能コンサルタント、SAP Basisスペシャリスト）の責任範囲を特定しました。



最初の部分で紹介した一般的なスキームで、彼は私が今考慮する要素を指定しました-これらはweb.xml、web-j2ee-engine.xml記述子、およびauthschemes.xml認証スキームXMLファイルです。







web.xmlの認証の説明



繰り返しになりますが、web.xml記述子は、開発者がSAP NWDSを使用して編集する必要があることを思い出してください。 OSレベルで変更しないでください。



このハンドルは、Javaアプリケーションを含むJavaコンテナーを記述します。 このコンテナのレベルで、認証スキームを構成できます。



Javaコンテナレベルで認証設定を記述するには、web.xml記述子で<login-config> ... </ login-config>タグを使用する必要があります。 認証を記述するために必要なすべてのパラメーターを設定します。



Javaコンテナの場合、使用できる標準認証方法は4つだけです。





Kerberos認証またはSAML認証を使用する場合、web.xml記述子のみを使用して認証方法を記述するアプローチは機能しません！

次に、これら4つの認証方法について詳しく説明します。



BASIC認証方法は、ユーザーのログインとパスワードを入力するシステムが次のようなウィンドウを表示する場合です（ウィンドウの表示はユーザーのブラウザによって異なり、表示を制御することはできません）。







この認証方法は、デフォルトで1つのログインモジュールBasicPasswordLoginModuleを含むポリシー構成「基本」に関連付けられています。 このログインモジュールは、標準認証メカニズムUser Management Engine（UME）を介して、入力されたログインとパスワードを検証します。







BASIC認証方法は、次のタグを使用してweb.xmlハンドルで設定されます。 



<login-config> <auth-method>BASIC</auth-method> <realm-name>myRealm</realm-name> </login-config>


<realm-name>タグは、セキュリティスコープを指定します。 次の例を使用して、このセキュリティエリアの意味を説明します。



アプリケーション1とアプリケーション2の2つのアプリケーションを検討してください。両方のアプリケーションについて、web.xml記述子は、auth-method = BASICおよびrealm-name = MySecurityRealmを示しています。



ユーザーはアプリケーション1にアクセスし、アプリケーションはBASICフォームを介してユーザー名とパスワードを要求します。 ユーザーは資格情報を入力し、アプリケーション1に正常に認証されます。次に、ユーザーはアプリケーション2に進みます。両方のアプリケーションのレルム名は同じであるため、システムはユーザーに資格情報の再入力を求めません。名前はMySecurityRealmです。 アプリケーション2に別のレルム名が指定されている場合、アプリケーション2に切り替えると、システムはユーザーにユーザー資格情報の再入力を要求します。



フォーム認証方法 -これは、ユーザーが使いやすいインターフェイスを使用してユーザー名とパスワードを入力する場合です。



SAPはユーザー資格情報を入力するための独自のインターフェイスを提供し、通常は次のようになります。







標準インターフェイスには独自の設定がありますが、これらの設定については認証に関する一連の記事では説明しません。 標準インターフェイスは変更できるとしか言えません。たとえば、開発者を巻き込むことなく、写真やロゴを置き換えたり、機能をわずかに拡張したりできます。 しかし、どの会社でも、開発者の助けを借りて標準のログインおよびパスワード入力インターフェイスを完全に書き直したい場合があります。これも行うことができます。



標準インターフェイスを使用する場合は、Javaアプリケーションのweb.xmlハンドルで次のタグを定義するだけで十分です。 



 <login-config> <auth-method>FORM</auth-method> </login-config>


Javaアプリケーションで開発されたインターフェイスを使用する場合、web.xml記述子で次のタグを定義する必要があります。 



 <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/mylogin.jsp</form-login-page> <form-error-page>/myerror.jsp</form-error-page> </form-login-config> </login-config>


<form-login-page>タグは、開発されたログインページを設定します。 <form-error-page>タグは、ユーザー認証エラーが発生した場合のページを設定します。



FORM認証方法は、デフォルトで1つのログインモジュールBasicPasswordLoginModuleを含むポリシー構成「フォーム」にバインドされます。







CLIENT_CERT認証方式 -これは、アプリケーションがユーザーに認証用のユーザー証明書を提供するように要求するときです。 ユーザーにとっては、次のようになります。







CLIENT_CERT認証方式を使用するには、web.xml記述子で次のタグを定義する必要があります。 



 <login-config> <auth-method>CLIENT_CERT</auth-method> </login-config>


この認証方法は、ポリシー構成「client_cert」にバインドされています。デフォルトでは、ClientCertLoginModuleというログインモジュールが1つ含まれています。







DIGEST認証方式 。 この認証方法は、BASICおよびFORMの方法に似ています。 ユーザー名とパスワードの入力も求められます。 BIGまたはFORM認証方法の場合のように、DIGESTの場合にのみパスワードハッシュが送信され、パスワード自体は送信されません。 ただし、この認証方法は広く普及していません。 どうやら、DIGEST認証方法を使用するよりも通信チャネルのSSL暗号化を構成する方が簡単で論理的だからです。



この認証方法は、デフォルトで1つのログインモジュールDigestLoginModuleを含むポリシー構成「ダイジェスト」に関連付けられています。







web-j2ee-engine.xml記述子の認証スキームの説明



web.xmlと同様のweb-j2ee-engine.xml記述子は、開発者がSAP NWDSを介してのみ編集する必要があります。 OSレベルで変更しないでください。



この記述子では、web.xml記述子とは対照的に、認証スタック全体（つまり、システム内のログインモジュールのセット（ログインモジュール））を詳細に記述できます。



認証スタックの説明に加えて、web-j2ee-engine.xml記述子でポリシードメイン（<security-policy-domain>タグ）を指定する必要があります。 ポリシードメインはセキュリティドメインです（レルム名に類似）。 レルム名とポリシードメインの違いは次のとおりです。





web-j2ee-engine.xmlの構造は、次のリンクを使用してhelp.sap.comで詳しく説明されています。



authschemes.xml XMLファイルを介した認証スキームの説明



web.xmlおよびweb-j2ee-engine.xmlファイルの作成と編集が開発者のタスクである場合、UMEパラメーター：login.authschemes.definition.fileで定義されるauthschemes.xml XMLファイルは、SAP Basisスペシャリストの責任です。



このファイルはシステムデータベースにあり、標準のグラフィックツールであるConfigToolからアクセスできます。



ConfigToolへのLinuxパス
/usr/sap/[SID.BIZ/J00/j2ee/configtool/configtool.sh



authschemes.xmlファイルの場所を取得するには、ConfigToolの構成エディターモードに移動する必要があります。







ツリーメニューで、ディレクトリに移動します。

設定:: cluster_config-> system-> custom_global-> cfg-> services-> com.sap.security.core.ume.service-> persistent



このディレクトリにはauthschemes.xmlファイルが含まれており、アップロード、編集、ダウンロードして戻すことができます。 エンコードに注意してください。 OSレベルにアップロードし、編集して別のエンコーディングで保存すると、システムがそれを読み取れない可能性があるため、注意してください！



必要に応じて、テンプレートごとまたは最初から認証スキームを使用して独自のXMLファイルを作成することもできます。 UME login.authschemes.definition.fileパラメーターで新しいXMLファイルを指定することを忘れないでください。 また、すべての標準Web Dynpro JavaアプリケーションがこのXMLファイルで「authscheme-ref name」= defaultを検索し、Portal iViewsが「authscheme-ref name」= [defaultまたはUserAdminScheme]を検索することも忘れないでください。



これらのニュアンスがすべて明確であれば、標準のXMLファイルauthschemes.xmlの構造の調査を開始できます。



authschemes.xmlファイルの構造



認証スキーム（authschemes.xml）は、システム内のポータルアプリケーション、Web Dynpro Javaアプリケーション、およびポータルiViewで使用できる認証スキームのリストです。 開発者がコードを記述するときにUME APIを使用する場合、Java Webアプリケーションも認証スキームを使用できます。



アプリケーションがauthschemes.xmlに記述されていない認証スキームを参照している場合、またはアプリケーションに原則として認証スキームが記述されていない場合、UMEパラメーター：login.authschemes.defaultで指定された認証スキームがそのようなアプリケーションのユーザー認証に使用されます。



次の図では、authschemes.xml XMLファイルの構造を示しています。







図からわかるように、authschemes.xmlファイルは認証スキーム（Authscheme 1、Authscheme 2、...、Authscheme N）と認証スキームへのリンクのリスト（Authscheme-ref 1、Authscheme-ref 2など）で構成されています。 認証スキームとそれらへのリンクは、設計要件に応じて、任意の数にすることができます。



おそらく、リンク（参照または参照）から始めます。 ここではすべてが簡単です。 リンクの名前は<authscheme-ref name>タグに書き込まれ、ネストされたタグで参照する認証スキームの名前が示されます。 繰り返し述べたように、すべての標準ポータルiViewおよびWeb Dynpro Javaアプリケーションは、事前定義されたRef：「default」および「UserAdminScheme」を使用します。 さらに、標準のXMLファイルauthschemes.xmlをよく見ると、「default」と「UserAdminScheme」が同じ認証スキームuidpwdlogonにつながっていることがわかります。







たとえば、ユーザーiVIewとiViewユーザー管理者に異なる認証スキームが必要な場合、認証スキームをuipwdlogonから他の認証スキームに変更することでこれを行うことができます。たとえば、リンク<authscheme-ref name =” UserAdminScheme”>のMyOwnAuthSchemeです。



ただし、authschemes.xmlでのリンクの使用は、一般的には使用できない機能です。 認証スキームを使用するアプリケーションでは、authschemes.xmlで定義されている認証スキームのいずれかをすぐに参照できます。



authschemes.xmlファイルの各AuthSchemeには、独自のパラメーターセットがあります。





認証テンプレート。 これは、事前定義されたポリシー構成です。その作成と内容については、SAP Netweaver AS Javaでの認証のセットアップに関する一連の記事の第3部で説明します。 テンプレートとして、これらのポリシー構成のいずれかを指定する必要があります。 ログインモジュールがポリシー設定で説明されていることを考慮すると、認証スキームは使用する必要があるシステム内の登録モジュールを認識します。



優先順位 例を使用して、このパラメーターの意味を説明しようとします。 2つのアプリケーションがあります。





AuthUserPassの優先度= 20、AuthCertの優先度= 40とします。ユーザーがアプリケーション1（識別子とパスワードによる）で認証され、アプリケーション2（証明書による認証を要求）に切り替えられた場合、ユーザーはアプリケーション2での認証のためにクライアント証明書を提示する必要があります、AuthCert（40）> AuthUserPass（20）が優先されるため。 反対のオプションを検討してください-アプリケーション2で（証明書により）認証され、アプリケーション1に切り替えられたユーザー（ログインとパスワードによる認証を要求します）。 AuthCert（40）> AuthUserPass（20）が優先されるため、システムはユーザー名とパスワードを要求せずにユーザーをアプリケーション1に入れます。



フロントエンドタイプ。 システムとユーザー間の対話のために呼び出されるインターフェースのタイプを定義します。 次のオプションが可能です：0、1、2：





フロントエンドターゲット ユーザーと対話して資格情報を提供するときに、システムによって起動されるアプリケーションを示します。 標準のauthschemes.xmlファイルでは、さまざまな認証スキームのフロントエンドターゲットがアプリケーションとして指定されています。







これらは、同じポータルアプリケーションcom.sap.portal.runtime.logonに属するポータルコンポーネントです。 このポータルアプリケーションは、SAPシステムのOSレベルで見つけることができ、開発者の助けを借りて、それを改良します。



Linux OSレベルのLinuxアプリケーションcom.sap.portal.runtime.logon
/usr/sap/[SID.BIZ/J00/j2ee/cluster/apps/sap.com/com.sap.portal.runtime.logon/ servlet_jsp / com.sap.portal.runtime.logon / com.sap.portal.runtime .logon.war



このアプリケーションは、SAPポータルコンテンツディレクトリにもあります。











おわりに



この記事では、web.xmlおよびweb-j2ee-engine.xml記述子の構造を調べました。 authschemes.xml XMLファイルの構造も考慮されました。 質問があれば、コメントを書いて、答えようとします。



SAP Netweaver AS Javaでの認証の設定に関するシリーズの次のパートでは、ポリシー設定とそれらを使用して実現できる可能性について説明します。


More articles:


All Articles