目次


WebSphere Portal と IBM Worklight による卓越したモバイル Web エクスペリエンスの提供

(パート 3) Worklight と WebSphere Portal を使用した自動シングル・サインオンの実装

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: WebSphere Portal と IBM Worklight による卓越したモバイル Web エクスペリエンスの提供

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:WebSphere Portal と IBM Worklight による卓越したモバイル Web エクスペリエンスの提供

このシリーズの続きに乞うご期待。

この記事では、ハイブリッド IBM Worklight アプリケーションをセットアップして、シングル・サインオン (SSO) を使用するように構成したサーバーへのユーザーの自動ログインを起動時に行うとともに、同じホスト上に IBM WebSphere Portal サーバーを配置する方法について説明します。SSO を使用するようにサーバーをセットアップすると、ユーザーは Worklight サーバーに 1 度ログインするだけで、同じホスト上にある他のサーバーで自動認証されるようになります。

モバイル・アプリケーションの多くはユーザー資格情報を保管する機能も備えており、アプリケーションを開くだけで資格情報を確認できます。この機能をサンプル・アプリケーションに追加するには、Worklight の暗号化されたキャッシュを実装して、今後のログイン試行のためにユーザー・ログイン情報を格納します。これにより、ユーザーはアプリケーションを開いて、Worklight と WebSphere Portal の 2 つのサーバーを通じてアカウントにログインできるようになります。

前提条件

この記事では WebSphere Portal V8 と Worklight V5.0.0.3 を使用しています。ここでは WebSphere Portal を使用していますが、LDAP ユーザー・レジストリーと LTPA トークン認証を使用した SSO をサポートしているサーバーであれば、これらの設定の正しい構成に適合するはずです。

この演習を進める前に以下の点を確認してください。

  • LDAP サーバーがインストールされ、実行されている。
  • WebSphere Portal V8 サーバーがインストールされ、実行されている。
  • デフォルトの Liberty Profile と Derby データベースを使用して IBM Worklight Server がインストールされている。

Worklight を実行する Liberty Profile サーバーと WebSphere Portal サーバーの間で SSO をセットアップするため、この 2 つのサーバーが同じユーザー・レジストリーを使用し、LTPA 鍵を共有するように構成する必要があります。また、SSO の対象となる、指定されたドメインを使用するように設定する必要もあります。

Liberty Profile サーバーをセットアップする

デフォルトの Liberty Profile と Derby データベースを使用して Worklight Server をインストールしたら、LDAP サーバーを使用するように Worklight Server を構成する必要があります。server.xml ファイル内で別途指定する場合を除き、Liberty Profile は使用するデフォルト値のセットで構成を処理します。このファイルの場所は、Linux と Windows のどちらを使用しているかで異なります。

  • Linux: <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/server.xml
  • Windows: <WorklightInstallDirectory>\WAS85liberty-server\server\wlp\usr\servers\worklightServer\server.xml

server.xml ファイル内で次の変更を行います。

  1. WebSphere Portal サーバーと競合しないように JSESSION Cookie の名前を変更します。そのためには、リスト 1 のように Cookie の名前属性を設定した httpSession XML タグを httpEndpoint 終了タグの後に追加します。
    リスト 1. JSESSIONID の名前変更
    <httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"> 
       <!-- Begin of options added by IBM Worklight installer. --> 
       <tcpOptions soReuseAddr="true"/> 
       <!-- End of options added by IBM Worklight installer. --> 
    </httpEndpoint> 
    <httpSession cookieName="JSESSIONID_wl"/>
  2. インストール済みのデフォルトのユーザー・レジストリーを削除します。複数のユーザー・レジストリーをアクティブにすると、サーバーでエラーが発生します。リスト 2 で示した basicRegistry セグメントを見つけて削除します。
    リスト 2. 基本レジストリー項目
    <!-- Declare the user registry for the IBM Application Center. --> 
    <basicRegistry id="applicationcenter-registry" realm="ApplicationCenter"> 
    <!-- The user "appcenteradmin" has special privileges within the IBM
         Application Center. -->
    	    <user name="appcenteradmin" password="admin"/> 
    	    <!-- The other users have normal privileges. --> 
    	    <user name="demo" password="demo"/> 
    	    <group name="appcentergroup"> 
    	        <member name="appcenteradmin"/> 
    	        <member name="demo"/> 
    	    </group> 
    </basicRegistry>
  3. 次に、LDAP ユーザー・レジストリーを追加します。リスト 3 は使用される構成の例を示しています。ただし、太字の情報は LDAP のセットアップ方法に応じて変更する必要があります。Liberty Profile は、LDAP サーバーの他の側面 (グループなど) に対象を限定する userFilter のような付加的なフィルターも備えています。さらに、SSL を使用するように LDAP サーバーをセットアップした場合は、その構成用のオプションも利用できます。server.xml の構成オプションまたは SSL を使用している LDAP サーバーへの接続方法の詳細については、インフォメーション・センターを参照してください。
    リスト 3. LDAP 構成の XML
    <ldapRegistry id=”ldap” 
        realm=”defaultWIMFileBasedRealm” 
        host=”<ldap host>” 
        port=”389” 
        ignoreCase=”true”
        baseDN=”dc=ibm,dc=com”
        bindDN=”cn=root”
        userFilter=”(&(uid=%v)(objectclass=inetOrgPerson))”
        bindPassword=”<password>”
        ldapType=”IBM Tivoli Directory Server”>
    </ldapRegistry>
  4. 正しいドメインに設定されている SSO Cookie を使用するようにサーバー・セキュリティーを変更します。この設定は ldapRegistry 項目のすぐ後で行うことができます。対象にするドメインの代わりに下記の太字のドメイン名を使用します。

    <webAppSecurity singleSignonEnabled=”true” ssoDomainNames=”.some.domain.com”/>

  5. 構成を再確認して LDAP 鍵を生成するには、サーバーを起動します。 <WorklightInstallDirectory>/server/wlp/bin にナビゲートし、次のコマンドを実行してサーバーを起動します。
    • Linux: sudo ./server start worklightServer
    • Windows: server.bat start worklightServer
    今回の構成でサーバーが正常に起動していることをログ・ファイルを調べて確認します。
    • Linux: <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/logs/console.log
    • Windows: <WorklightInstallDirectory>\WAS85liberty-server\server\wlp\usr\servers\worklightServer\logs\console.log
  6. サーバーを停止します。
    • Linux: sudo ./server stop worklightServer
    • Windows: server.bat stop worklightServer

WebSphere Portal サーバーをセットアップする

  1. WebSphere Portal サーバーの LDAP をセットアップするには、リスト 4 で示した構成情報の一部を使用して、LDAP 値に基づいて ldapConfig.properties ファイルを作成します。使用するサーバーの構成に基づいて、これらのプロパティーの大部分の値を置き換える必要があります。これらの値は、Liberty Profile サーバーの LDAP 構成の多くで使用された値と一致するはずです。
    リスト 4. Portal LDAP のプロパティー
    WasPassword=<WAS PW> 
    PortalAdminPwd=<Portal PW> 
    federated.ldap.id=myLDAP 
    federated.ldap.host=<host> 
    federated.ldap.ldapServerType=IDS 
    federated.ldap.port=389 
    federated.ldap.baseDN=dc=ibm,dc=com 
    federated.ldap.bindDN=cn=root 
    federated.ldap.bindPassword=<LDAP bind PW> 
    federated.ldap.et.personaccount.objectClasses=inetOrgPerson 
    federated.ldap.et.personaccount.objectClassesForCreate=inetOrgPerson 
    federated.ldap.et.personaccount.searchFilter= 
    federated.ldap.et.group.objectClasses=groupOfUniqueNames 
    federated.ldap.et.group.objectClassesForCreate=groupOfUniqueNames 
    federated.ldap.et.group.searchFilter= 
    federated.ldap.gm.dummyMember=uid=dummy 
    federated.ldap.gm.groupMemberName=uniqueMember 
    federated.ldap.gm.objectClass=groupOfUniqueNames 
    federated.ldap.gm.scope=nested 
    federated.ldap.loginProperties=uid;mail 
    personAccountParent=cn=users,dc=ibm,dc=com 
    groupParent=cn=groups,dc=ibm,dc=com 
    personAccountRdnProperties=uid 
    groupRdnProperties=cn 
    federated.ldap.attributes.mapping.ldapName=mail, title 
    federated.ldap.attributes.mapping.portalName=ibm-primaryEmail,
    ibm-jobTitle
  2. このファイルの作成と構成が完了したら、ファイルを WebSphere Portal マシンに移動して、リスト 5a または 5b の ConfigEngine タスクを実行します。
    リスト 5a. ConfigEngine タスク: パート 1 (Linux)
    ./ConfigEngine.sh -DparentProperties=<file location> -DsaveParentproperties=true 
    ./ConfigEngine.sh validate-federated-ldap 
    ./ConfigEngine.sh wp-create-ldap 
    ./ConfigEngine.sh wp-set-entitytypes
    リスト 5b. ConfigEngine タスク: パート 1 (Windows)
    ConfigEngine.bat -DparentProperties=<file location> -DsaveParentproperties=true 
    ConfigEngine.bat validate-federated-ldap 
    ConfigEngine.bat wp-create-ldap 
    ConfigEngine.bat wp-set-entitytypes
  3. ポータル・サーバーを再起動し、リスト 6a または 6b のタスクを続行します。
    リスト 6a. ConfigEngine タスク: パート 2 (Linux)
    ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config 
    ./ConfigEngine.sh wp-update-federated-ldap-attribute-config
    リスト 6b. ConfigEngine タスク: パート 2 (Windows)
    ConfigEngine.bat wp-validate-federated-ldap-attribute-config 
    ConfigEngine.bat wp-update-federated-ldap-attribute-config
  4. LDAP が統合されると、LDAP とポータルの両方で同じログイン情報を使用しているユーザーが複数存在する場合、そのユーザー・ログインが不確実なものになる可能性があります。これを修正するには、完全修飾ユーザー名を使用してログインします。 ブラウザーを開いて WebSphere Application Server 管理コンソールに移動し、ログインして、「セキュリティー」 > 「グローバル・セキュリティー」 > 「Web および SIP セキュリティー」 > 「シングル・サインオン (SSO)」の順にナビゲートします (図 1)。
    図 1. 認証メカニズムと有効期限
  5. ドメイン名が Liberty Profile で使用しているものと同じであることを確認し、LTPA Cookie 名を「インターオペラビリティー・モード」で表示されている名前に設定します。完了したら、「OK」をクリックして変更内容を保存します
    図 2. シングル・サインオン (SSO) のプロパティー
  6. Worklight サーバー上にある LTPA 鍵をローカル・マシンにコピーします。これらの鍵は WebSphere Portal にインポートする必要があります。Worklight サーバー上の LTPA 鍵ファイルは、次の場所にあります。
    • Linux: <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/resources/security/ltpa.keys
    • Windows: <WorklightInstallDirectory>\WAS85liberty-server\server\wlp\usr\servers\worklightServer\resources\security\ltpa.keys
  7. 次に、WebSphere Application Server 管理コンソール内で「セキュリティー」 > 「グローバル・セキュリティー」に戻ります。「グローバル・セキュリティー」ページの 「Web および SIP セキュリティー」の上にある「認証」セクションの上部に「LTPA」が表示されています (図 1)。このページのフォームの下部で、パスワードとして WebAS を入力します。これは、Liberty Profile の鍵をインポートする場合のデフォルト・パスワードです。独自の鍵を使用する場合は、適切なパスワードを入力します。完全修飾の鍵ファイル名として、ltpa.keys ファイルのパスとファイル名を入力します (図 3)。完了したら、「鍵のインポート」をクリックし、もう一度変更内容を保存します
    図 3. グローバル・セキュリティー
  8. ここで、WebSphere Portal サーバーを再起動します。

Worklight アプリケーションをセットアップする

これ以降、Worklight アプリケーションを作成することができます。そのためには、Liberty サーバーの WAR ファイルと実際のクライアント・サイド・アプリケーションを作成します。

  1. Worklight 開発環境を開き、プロジェクト名が SSODemo、アプリケーション名が SSODemoAppハイブリッド・アプリケーションを新規に作成します。次に、このプロジェクトに新しい Android 環境を追加します。プロジェクト・エリアは図 4 のようになります。
    図 4. プロジェクト・フォルダー
  2. Liberty サーバー用に WAR ファイルを正しく構成するには、「設計」ビューで application-description.xml の worklightServerRootURL をまず変更し、Liberty Profile サーバー上の Worklight サーバーの場所 (例: http://host.domain.com:9080/SSODemo) を指すようにする必要があります。パスにプロジェクト名が含まれているのが分かります。このパスに Worklight WAR ファイルをデプロイします。
    図 5. サーバーのルート URL
  3. SSODemo/server/conf/worklight.properties で、リスト 7 に表示されている値のアンコメントと変更を行います。
    リスト 7. Worklight サーバー・プロパティー
    publicWorkLightHostname=host.domain.com
    publicWorkLightProtocol=http 
    publicWorkLightPort=9080 
    publicWorkLightContext=/SSODemo 
    
    wl.db.jndi.name=jdbc/WorklightDS 
    wl.db.type=DERBY 
    wl.db.url=jdbc:derby:${worklight.home}/derby/WorklightDB;create=true 
    wl.reports.db.url=jdbc:derby:${worklight.home}/derby/WorklightReportsDB;create=true
  4. ファイルを保存し、SSODemo/server/conf/authenticationConfig.xml を「ソース」ビューで開きます。<realms> エレメントの前に <securityTests> XML を追加します (リスト 8 参照)。
    リスト 8. セキュリティー・テスト
    <securityTests>
        <mobileSecurityTest name="mobileTests"> 
            <testDeviceId provisioningType="none" /> 
            <testUser realm="WASLTPARealm" /> 
        </mobileSecurityTest> 
        <customSecurityTest name="WASLTPARealmTests"> 
            <test realm="WASLTPARealm" isInternalUserID="true"/> 
        </customSecurityTest> 
    </securityTests>
  5. リスト 9 に表示されている、For websphere というラベルの付いたセキュリティー・レルムをアンコメントします。
    リスト 9. セキュリティー・レルム For WebSphere
    <!-- For websphere --> 
    <realm name="WASLTPARealm" loginModule="WASLTPAModule">
       <className>com.worklight.core.auth.ext.WebSphereFormBasedAuthenticator
           </className> 
       <parameter name="login-page" value="/login.html"/> 
       <parameter name="error-page" value="/loginError.html"/> 
       </realm>
  6. ログイン・モジュール For websphere をアンコメントします (リスト 10)。
    リスト 10. ログイン・モジュール For WebSphere
    <!-- For websphere --> 
    <loginModule name="WASLTPAModule"> 
        <className>com.worklight.core.auth.ext.WebSphereLoginModule</className> 
        </loginModule>
  7. 「設計」ビューの SSODemo/apps/SSODemoApp/application-descriptor.xml ファイルに戻ります。メイン・アプリケーションで、「共通 (オプション)」セクションの下に WASLTPARealmTests のセキュリティー・テストを追加します (図 6)。
    図 6. メイン・アプリケーションのセキュリティー・テスト
  8. 「Android の電話およびタブレット」の「詳細」で、mobileTests のセキュリティー・テストを追加します。
    図 7. Android セキュリティー・テスト
  9. このファイルを保存すると、WAR ファイルが bin フォルダーに自動生成されます。作成された WAR ファイルを編集のために別のロケーションへコピーします。WAR ファイルは <workspace>/bin/SSODemo.war にあります。
  10. 10. Liberty Profile サーバーへの認証を完全に可能にするには、WAR ファイルでいくつか微調整を行う必要があります。シンプルな login.html と loginError.html を WAR ファイル内に配置する必要があります。リスト 11 および 12 に表示されている内容を使用してこれらのファイルを作成します。
    リスト 11. login.html のファイル内容
    <html> 
        <head> 
            <title>Login</title> 
        </head> 
        <body> 
            <form method="post" action="j_security_check"> 
                <label for="j_username">User name:</label> 
                <input type="text" id="j_username" name="j_username" /> 
                <br /> 
                <label for="j_password">Password:</label> 
                <input type="password" id="j_password" name="j_password" /> 
                <br /> 
                <input type="submit" id="login" name="login" value="Log In" /> 
            </form> 
        </body> 
        </html>
    リスト 12. loginError.html のファイル内容
    <html> 
        <head></head> 
        <body> 
            Login Error 
        </body> 
    </html>
  11. アーカイブ・マネージャーで SSODemo.war ファイルを開き、この 2 つの HTML ファイルを WAR の最上位ディレクトリーに追加します (図 8)。
    図 8. WAR ファイルに追加された login.html と loginError.html
  12. 次に、WAR の WEB-INF フォルダーにナビゲートし、図 9 で強調表示されている web.xml ファイルを編集して、リスト 13 の XML を右下の web-app 終了タグの前に挿入します。
    図 9. WAR ファイルでの web.xml のロケーション
    リスト 13. web.xml login-config XML
    <login-config> 
        <auth-method>FORM</auth-method> 
        <form-login-config> 
            <form-login-page>/login.html</form-login-page> 
            <form-error-page>/loginError.html</form-error-page> 
        </form-login-config> 
        </login-config>
  13. この編集済みの WAR ファイルを Liberty Profile サーバーの <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/apps ディレクトリーにアップロードします。
  14. Liberty Profile の server.xml を Worklight Server 用に再度変更し、この新規アプリケーションを組み込みます。ファイルは以下のロケーションにあります。
    • Linux: <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/server.xml
    • Windows: <WorklightInstallDirectory>\WAS85liberty-server\server\wlp\usr\servers\worklightServer\server.xml
  15. applicationcenter アプリケーションの宣言の後に、リスト 14 に表示されている新規アプリケーションのタグを追加します。
    リスト 14. server.xml へのアプリケーションの追加
    <application id="ssodemo" location="SSODemo.war" name="SSODemo" type="war"> 
        <classloader delegation="parentLast"> 
        <commonLibrary> 
             <fileset dir="${shared.resource.dir}/lib" 
    		includes="worklight-jee-library.jar"/> 
        </commonLibrary> 
        </classloader> 
    </application>
  16. これで、Liberty Profile サーバーはクライアント・サイドのコードを処理するように完全に構成されました。このコードは次のセクションで開発します。<WorklightInstallDirectory>/server/wlp/bin にナビゲートし、次のコマンドを実行してサーバーを起動します。
    • Linux: sudo ./server start worklightServer
    • Windows: server.bat start worklightServer
  17. Worklight コンソール (http://host.domain.com:9080/SSODemo/console/) に移動します。

クライアント・サイド・アプリケーションをセットアップする

これでサーバーの WAR ファイルが作成されました。次に Worklight アプリケーションが開発環境で正しくコンパイルされるように、変更をいくつか加える必要があります。この変更が必要なのは、すべてのパッケージを確実にコンパイルするには、内部の Jetty サーバーにアプリケーションを正しくデプロイしなければならないためです。Jetty サーバーはログインに必要な WebSphere クラスを保持していないため、ログインに失敗します。

  1. worklight.properties ファイルに戻り、リスト 7 の変更されたすべての行を再コメント化します。これにより、リスト 15 のようになります。
    リスト 15. Worklight サーバー・プロパティー
    #publicWorkLightHostname=host.domain.com
    #publicWorkLightProtocol=http 
    #publicWorkLightPort=9080 
    #publicWorkLightContext=/SSODemo 
    
    #wl.db.jndi.name=jdbc/WorklightDS 
    #wl.db.type=DERBY 
    #wl.db.url=jdbc:derby:${worklight.home}/derby/WorklightDB;create=true 
    #wl.reports.db.url=jdbc:derby:${worklight.home}/derby/WorklightReportsDB;
    	create=true
  2. authenticationConfig.xml に移動し、以前にアンコメントした for websphere セクションを再コメント化します (リスト 16 および 17 参照)。
    リスト 16. セキュリティー・レルム For WebSphere
    <!-- For websphere --> 
    <!--realm name="WASLTPARealm" loginModule="WASLTPAModule">
    <className>com.worklight.core.auth.ext.WebSphereFormBasedAuthenticator
    	</className> 
    <parameter name="login-page" value="/login.html"/> 
    <parameter name="error-page" value="/loginError.html"/> 
    </realm-->
    リスト 17. ログイン・モジュール For WebSphere
    <!-- For websphere --> 
    <!--loginModule name="WASLTPAModule"> 
        <className>com.worklight.core.auth.ext.WebSphereLoginModule</className> 
    </loginModule-->
  3. 偽のレルムとログイン・モジュールを追加します (リスト 18 および 19 参照)。
    リスト 18. WASLTPA 偽レルムの追加
    <realm loginModule="WASLTPAModule" name="WASLTPARealm">
        <className>com.worklight.core.auth.ext.FormBasedAuthenticator</className>
    </realm>
    リスト 19. WASLTPA 偽ログイン・モジュールの追加
    <loginModule name="WASLTPAModule">
    <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className>
    </loginModule>

    使用しているセキュリティー・レルムを変更するには、WAR ファイルの作成に関する前述のセクションに再度従う必要があります。次に、最後のいくつかの手順に再度従って、完了済みの WebSphere モジュールを元に戻します。

  4. アプリケーションに必要な HTML を追加します (SSODemo/apps/SSODemoApp/common/SSODemoApp.html)。リスト 20 のコード・セグメントで構成されるように HTML の body を変更します。
    リスト 20. SSODemoApp.html body HTML
    <body id="content" style="display: none"> 
        <div id="AppBody">
            <div class="wrapper"> 
                <iframe id="portalframe" src="" style="border:'0px none'" width="100%”
                    height="640px"></iframe>
            </div>
        </div>
        <div id="AuthBody" style="display: none"> 
            <div id="loginForm"> 
                Username:<br/> 
                <input type="text" id="usernameInputField" autocorrect="off" 
                    autocapitalize="off" /><br /> 
                Password:<br/> 
                <input type="password" id="passwordInputField" autocorrect="off" 
                    autocapitalize="off"/><br/>		 
                <input type="button" id="loginButton" value="Login" /> 
                <input type="button" id="cancelButton" value="Cancel" /> 
            </div> 
        </div> 
        <script src="js/initOptions.js"></script> 
        <script src="js/SSODemoApp.js"></script> 
        <script src="js/messages.js"></script> 
        <script src="js/challengeResponse.js"></script> 
    </body>

    これにより、コンテンツ領域と認証領域の 2 つのセクションが HTML の body に追加されます。現在のコンテンツ領域は、Worklight への認証後にポータル・ページを開き、SSO が機能していることを示す IFrame のみです。
  5. さらに、js/challengeResponse.js のスクリプト・タグが追加されました。このファイルは新規に作成され、ログインの処理が必要なクライアント・サイドの局面に対処します。このコードはダウンロード可能であり、モジュール 20.1 のフォーム・ベースの認証で作成されたチャレンジ・ハンドラーに主に基づいていますが、自動認証に対応するために暗号化キャッシュを調べて保存されたログインを確認できるように一部変更されています。ログインが見つからない場合はユーザーのログインを許可し、その情報を保存して以降の自動認証で使用します。図 10 は challengeResponse.js ファイルの保管場所を示しています。
    図 10. challengeResponse.js のロケーション
  6. セキュリティー課題が検出され、この challengeResponse.js ファイルの handleChallenge 関数に送信されると、ビジー・インジケーターが呼び出されて、暗号化キャッシュを開いて資格情報の確認処理が行われていることがユーザーに伝えられます。暗号化キャッシュは、コールバック・ハンドラーによる非同期コールのみを通じて機能します。したがって、各チェックはこれらのコールバック内で行われる必要があります。ユーザー名とパスワードの値がともに暗号化キャッシュで設定されている場合は、ユーザー・ログインのためにこの情報のフォーム送信が行われます。ログインが見つからない場合は認証本体が提示されるので、ユーザーはその情報を手動で入力してログインすることができます。ユーザーが「送信」をクリックすると、資格情報は保存されて以降のログインで使用されます。
  7. ログインが完了すると、ポータルをロードするように変更された IFrames ソースとともにアプリケーション本体を表示できます。ログインの成功後にポータルはロードされます。そうでない場合は、SSO に対する正しい LTPA トークンを含まない状態でロードされます。ページ・ロードでの認証は未完了であり、これらの認証チャレンジは XHR によって行われ、完全なページ・ロードは実行されていないからです。
  8. challengeResponse.js ファイルの追加と正しいポータル URL およびレルム名 (例: WASLTPARealm) への更新が完了したら、「Android」 環境を右クリックし、「実行」 > 「すべてをビルドしてデプロイ」を選択して wlapp ファイルを新規に作成し、Worklight サーバーにデプロイします。サーバーの Worklight コンソールを開き (http://worklight.domain.com:9080/SSODemo/console/)、アプリケーションやアダプターのデプロイのオプションがある画面上部でファイルを選択し、Worklight SSODemo ワークスペースにナビゲートします。bin フォルダー内にファイル SSODemoApp-all.wlapp があります。このファイルを選択して送信します。これでアプリケーションはデプロイされ、図 11 のように表示されるはずです。
    図 11. デプロイされた SSODemo app
  9. 開発環境に戻り、Android 環境が追加されたプロジェクト SSODemoSSODemoAppAndroid を見つけます。このプロジェクトを右クリックし、「実行」 > 「Android アプリケーション」を選択します。
  10. 11. エミュレーターまたは物理デバイスでアプリケーションがロードされると、ログイン・パネルが表示されます。LDAP のユーザーを使用してログインします。ポータルのフロントページのログインにも同じ LDAP ユーザーが使用されます。アプリケーションを閉じて後で再び開くと、ユーザー・ログインが自動的に行われることに気づきます。

トポロジーの選択

Worklight と WebSphere Portal のデプロイメントの計画にあたっては、サーバー・トポロジーの選択について考慮します。IBM Worklight Server と WebSphere Portal では、プロキシー・サーバーまたは HTTP サーバーが必要になる場合があります。同じシステム上に各サーバーが配置されていないときに、1 つの URL (WebSphere Portal と Worklight で共通のホスト名) をユーザーと共有する必要がある場合は、このサンプルをデプロイするためにプロキシー・サーバーまたは HTTP サーバーが必要となります。Worklight の教育用モジュール 45 には、WebSphere Portal サーバーでホストされている Web サイトなど、リモート Web サイトの使用方法が説明されています。

加えて、このサーバー・インスタンスの主な目的は、ルーティング・ルールとロード・バランシング方式に基づいて、バックエンドのサーバー・クラスターに要求を送信可能なサロゲートとして機能することです。HTTP プラグインで構成された HTTP サーバーと WebSphere Application Server プロキシー・サーバーのいずれを使用しても、WebSphere Application Server、クラスター、または Web サーバーによって処理される要求のロード・バランシングを行うことができます。

複数のホスト間で経路指定するために Web サーバー (プラグイン) を WebSphere Application Server Liberty Profile で構成する必要がある場合は、インフォメーション・センターの文書「Liberty プロファイルの Web サーバー・プラグインの構成」を参照してください。

プロキシーと HTTP プラグインのいずれを使用するかで違いが生じます。各ソリューションの利点について知るには、記事「Proxy server versus the HTTP plug-in - Choosing the best WebSphere Application Server workload management option」を参照してください。

Web サーバー・プラグインまたはプロキシーのインストールと構成の詳細については、次の参考資料を参照してください。

Conclusion

この記事では、ユーザー・ログインを自動化し、シングル・サインオンによって追加のログインなしに WebSphere Portal サーバーへのユーザー・アクセスを可能にする Worklight ハイブリッド・アプリケーションの作成方法について説明しました。これにより、アプリケーションを開いたらすぐにアカウントにアクセスして使用できる、多くのモバイル・ユーザーが馴染んでいる利便性が実現します。

この演習をさらに展開させる方法として、ユーザーがその資格情報を削除して異なるログインを使用できるようにする機能の追加があります。この作業は、ユーザーの要求時に資格情報の値を暗号化キャッシュから削除し、ページを再ロードして新しいログインをトリガーするだけで行うことができます。もう 1 つの領域は、ログインの失敗時に返されるエラー・メッセージによってユーザーのログインが無効であるかどうかを判定し、キャッシュの値を削除してユーザーが新しい値で再度サインインできるようにすることです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=974838
ArticleTitle=WebSphere Portal と IBM Worklight による卓越したモバイル Web エクスペリエンスの提供: (パート 3) Worklight と WebSphere Portal を使用した自動シングル・サインオンの実装
publish-date=06202014