Proporcione uma Experiência da Web Móvel Excepcional Usando o WebSphere Portal e o IBM Worklight V5.0, Parte 3: Implementando conexão única automática com Worklight e WebSphere Portal

Cada vez mais as empresas estão fornecendo suporte em vários canais para suas comunidades de canal da web. Este artigo explica como o IBM WebSphere Portal e o IBM Worklight permitem às empresas criar aplicativos Worklight capazes de efetuar o login do usuário automaticamente na inicialização, ao mesmo tempo também usando a conexão única para efetuar o login do usuário em um servidor do WebSphere Portal no mesmo host ao mesmo tempo. Isso torna fácil para os aplicativos móveis exibir páginas do portal personalizadas para o usuário de dentro do aplicativo.

Este artigo se aplica ao IBM Worklight V5.x. Há outra versão disponível deste aplicativo que se aplica ao IBM Worklight V6.0.

Spencer Brooks, Front-end engineer, O IBM

Spencer Brooks é engenheiro de Front-end no Research Triangle Park Development Lab da IBM. Durante seu período no desenvolvimento de WebSphere Portal, ele contribuiu principalmente com o desenvolvimento do tema.



26/Nov/2013

Introdução

Obtenha o Worklight agora

Faça o download do IBM Worklight Developer Edition 6.0 agora gratuitamente e sem data de expiração!

Este artigo descreve como configurar um aplicativo IBM Worklight híbrido que efetue login do usuário automaticamente na inicialização em um servidor que foi configurado com conexão única e possui um servidor IBM WebSphere Portal no mesmo host. Ter os servidores configurados com o SSO permite aos usuários simplesmente efetuar login uma vez no servidor Worklight e então ser automaticamente autenticado para os outros servidores no mesmo host.

Muitos aplicativos móveis também oferecem a habilidade de armazenar as credenciais do usuário de modo que seja possível simplesmente abrir o aplicativo e ver essas informações. Para adicionar isso ao aplicativo de amostra, é possível implementar o cache criptografado do Worklight para armazenar as informações de login do usuário para futuras tentativas de login. Isso permite aos usuários abrir o aplicativo e ser conectado às suas contas tanto no servidor do Worklight quanto no servidor do WebSphere Portal.

Pré-requisitos

Este artigo usa o WebSphere Portal V8 e o Worklight V5.0.0.3. Embora o WebSphere Portal seja usado aqui, qualquer servidor com suporte para conexão única por meio de um registro de usuário LDAP e uma autenticação de token LTPA deve ser compatível com a configuração correta desses ajustes.

Antes de continuar com este exercício, certifique-se de ter:

  • Um servidor do LDAP instalado e em execução.
  • Servidor do WebSphere Portal V8 instalado e em execução.
  • Servidor do IBM Worklight instalado usando o perfil Liberty padrão e banco de dados Derby.

Porque você configurará a conexão única entre um servidor de perfil Liberty executando Worklight e um servidor do WebSphere Portal, ambos os servidores precisam ser configurados para usar o mesmo registro de usuário, compartilhar chaves LTPA e ser definidos para usar o domínio especificado para a conexão única funcionar.


Configurar o servidor de perfil Liberty

Depois de instalar o Servidor do Worklight com o perfil Liberty padrão e o banco de dados Derby, o servidor precisa ser configurado para usar o servidor do LDAP. O perfil Liberty manipula a configuração por meio de um conjunto de padrões que usa, a menos que você especifique de outra forma no arquivo server.xml. Dependendo de se você está usando Linux® ou Windows®, este arquivo está localizado em:

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

Faça essas alterações dentro do arquivo server.xml:

  1. Altere o nome do cookie JSESSION de modo que ele não entre em conflito com o servidor do WebSphere Portal. Para fazer isso, adicione a tag XML httpSession depois da tag de fechamento httpEndpoint com o atributo de nome do cookie definido como mostrado na Listagem 1.
    Listagem 1. Alteração do nome de 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. Remova o registro do usuário padrão instalado. O servidor terá erros com vários registros de usuário ativos. Localize o segmento basicRegistry, mostrado na Listagem 2, e remova-o.
    Listagem 2. Entrada de registro básica
    <!-- 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. A seguir, você adicionará o registro do usuário LDAP. A Listagem 3 mostra um exemplo da configuração usada; porém, as informações em negrito precisarão ser alteradas dependendo de como você configura seu LDAP. O perfil Liberty também tem filtros adicionais, como o userFilter, apenas para outros aspectos do servidor do LDAP, como grupos. Além disso, se o seu servidor do LDAP estiver configurado para usar SSL, há opções que você pode usar para configurar isso também. Veja o Centro de Informações para saber mais sobre as opções de configuração do server.xml ou conectar-se a um servidor do LDAP que está usando SSL..
    Listagem 3. XML de configuração do LDAP
    <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. Altere a segurança do servidor para usar cookies SSO sendo definidos para o domínio adequado, o que pode ser definido diretamente na entrada ldapRegistry. Substitua o nome de domínio em negrito abaixo para o domínio em que você irá trabalhar:

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

  5. Para verificar novamente a configuração e gerar uma chave do LDAP, inicie o servidor. Navegue para <WorklightInstallDirectory>/server/wlp/bin e depois execute este comando para iniciar o servidor:
    • Linux: sudo ./server start worklightServer
    • Windows: server.bat start worklightServer
    Verifique o arquivo de log para garantir que o servidor tenha inicializado com sucesso com a sua configuração:
    • Linux: <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/logs/console.log
    • Windows: <WorklightInstallDirectory>\WAS85liberty-server\server\wlp\usr\servers\worklightServer\logs\console.log
  6. Pare o servidor:
    • Linux: sudo ./server stop worklightServer
    • Windows: server.bat stop worklightServer

Configurar o servidor do WebSphere Portal

  1. Para configurar o LDAP dos servidores do WebSphere Portal, você criará um arquivo ldapConfig.properties com algumas das informações de configuração mostradas na Listagem 4 com base nos valores do LDAP. Você precisará substituir os valores para a maioria dessas propriedades com base na configuração do seu servidor. Os valores devem corresponder àqueles usados para grande parte da configuração do LDAP do servidor de perfil Liberty.
    Listagem 4. Propriedades do LDAP do Portal
    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. Depois de criar e configurar esse arquivo, mova-o para a máquina do WebSphere Portal e então execute as tarefas do ConfigEngine na Listagem 5a ou 5b.
    Listagem 5a. Tarefas do ConfigEngine, parte 1 (Linux)
    ./ConfigEngine.sh -DparentProperties=<file location> -DsaveParentproperties=true 
    ./ConfigEngine.sh validate-federated-ldap 
    ./ConfigEngine.sh wp-create-ldap 
    ./ConfigEngine.sh wp-set-entitytypes
    Listagem 5b. Tarefas do ConfigEngine, parte 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. Reinicie o servidor do portal e continue com as tarefas nas Listagens 6a ou 6b.
    Listagem 6a. Tarefas do ConfigEngine, parte 2 (Linux)
    ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config 
    ./ConfigEngine.sh wp-update-federated-ldap-attribute-config
    Listagem 6b. Tarefas do ConfigEngine, parte 2 (Windows)
    ConfigEngine.bat wp-validate-federated-ldap-attribute-config 
    ConfigEngine.bat wp-update-federated-ldap-attribute-config
  4. Quando o LDAP tiver federado, é possível que seu login de usuário tenha se tornado ambíguo se houver mais de um usuário com o mesmo login tanto no LDAP quanto no portal. Para corrigir isso, use um nome de usuário totalmente qualificado para efetuar o login. Abra um navegador no console de administração do WebSphere Application Server, efetue login e navegue para Security > Global Security > Web and SIP security > Single sign-on (SSO) (Figura 1).
    Figura 1. Mecanismos de autenticação e expiração
  5. Certifique-se de que o nome de domínio seja o mesmo que o usado com o perfil Liberty e defina os nomes de cookie LTPA como mostrado com o modo de Interoperabilidade ligado. Depois de fazer isso, clique em OK e Save the changes.
    Figura 2. Propriedades do Single Sign-on (SSO).
  6. Copie as chaves de LTPA localizadas no servidor Worklight para a sua máquina local, pois elas serão precisarão ser importadas para o WebSphere Portal. O arquivo de chaves LTPA no servidor Worklight está localizado em:
    • 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. A seguir, no console de administração do WebSphere Application Server, navegue de volta para Security > Global Security. Na página Global Security acima de Web and SIP security, LTPA é exibido no topo da seção Authentication (Figura 1). No pé do formulário nessa página, digite a senha WebAS, que é o padrão para a chave de perfil do Liberty se você estiver importando essa. Se estiver usando sua própria chave, insira a senha adequada. Para um nome de arquivo de chave totalmente qualificado, digite o caminho e o nome de arquivo para o arquivo ltpa.keys (Figura 3). Depois de fazer isso, clique em Import keys e Save the changes novamente.
    Figura 3. Segurança global
  8. Agora reinicie o servidor do WebSphere Portal.

Configurar o aplicativo Worklight

Agora você pode criar seu aplicativo Worklight criando o arquivo WAR para o servidor Liberty e o aplicativo do lado do cliente real.

  1. Abra o ambiente de desenvolvimento do Worklight e escolha Create a new Hybrid Application com um nome de projeto de SSODemo e um nome de aplicativo de SSODemoApp. Então adicione o novo ambiente Android a este projeto. Sua área de projeto deve se parecer com a da Figura 4.
    Figura 4. Pastas do projeto
  2. Para configurar um arquivo WAR adequadamente para o servidor Liberty, é preciso primeiro modificar worklightServerRootURL em application-description.xml enquanto na visualização de Design para apontar onde o servidor Worklight estará no servidor do perfil Liberty, como http://host.domain.com:9080/SSODemo. Observe que o caminho inclui o nome do projeto, uma vez que você implementará o arquivo WAR do Worklight nesse caminho.
    Figura 5. URL raiz do servidor
  3. Em SSODemo/server/conf/worklight.properties, você deseja cancelar o comentário e alterar os valores mostrados na Listagem 7.
    Listagem 7. Propriedades do servidor 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. Salve o arquivo e então abra SSODemo/server/conf/authenticationConfig.xml na visualização Source. Antes do elemento <realms>, adicione o XML <securityTests> como mostra a Listagem 8.
    Listagem 8. Testes de segurança
    <securityTests>
        <mobileSecurityTest name="mobileTests"> 
            <testDeviceId provisioningType="none" /> 
            <testUser realm="WASLTPARealm" /> 
        </mobileSecurityTest> 
        <customSecurityTest name="WASLTPARealmTests"> 
            <test realm="WASLTPARealm" isInternalUserID="true"/> 
        </customSecurityTest> 
    </securityTests>
  5. Cancelar comentário no domínio de segurança mostrado na Listagem 9 que está rotulado como For Websphere.
    Listagem 9. Domínio de segurança para o 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. Cancelar o comentário do módulo de login para o websphere (Listagem 10).
    Lista 10. Módulo de login para o WebSphere
    <!-- For websphere --> 
    <loginModule name="WASLTPAModule"> 
        <className>com.worklight.core.auth.ext.WebSphereLoginModule</className> 
    </loginModule>
  7. Retorne para o arquivo SSODemo/apps/SSODemoApp/application-descriptor.xml na visualização de Design. No aplicativo principal, você deseja adicionar um teste de segurança de WASLTPARealmTests sob a seção Common (opcional) (Figura 6).
    Figura 6. Teste de segurança para o aplicativo principal
  8. Em telefones e tablets Android, em Details, adicione o teste de Segurança de mobileTests.
    Figura 7. Teste de segurança do Android
  9. Salve o arquivo e o arquivo WAR é automaticamente gerado na pasta da categoria. Copie o arquivo WAR criado para outro local para edição. O arquivo WAR está localizado em: <workspace>/bin/SSODemo.war.
  10. O arquivo WAR precisa de alguns ajustes para habilitar totalmente a autenticação para o servidor de perfil Liberty. Você precisa de um login.html e de um loginError.html simples para colocar no arquivo war. Crie esse arquivos com o conteúdo mostrado nas Listagens 11 e 12.
    Listagem 11. Conteúdos do arquivo 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>
    Listagem 12. Conteúdos do arquivo loginError.html
    <html> 
        <head></head> 
        <body> 
            Login Error 
        </body> 
    </html>
  11. Abra o arquivo SSODemo.war com um gerenciador de archive e adicione ambos os arquivos HTML no diretório de nível superior do WAR (Figura 8).
    Figura 8. login.html e loginError.html adicionados ao arquivo WAR
  12. A seguir, navegue para a pasta WEB-INF do WAR e edite o arquivo web.xml, destacado na Figura 9, para incluir o XML na Listagem 13 na parte inferior à direita, antes da tag de fechamento do aplicativo da web.
    Figura 9. Local do web.xml no arquivo WAR
    Listagem 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. Faça o upload desse arquivo WAR modificado para seu servidor de perfil do Liberty para o diretório <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/apps.
  14. Modifique o server.xml do perfil do Liberty para o Worklight Server novamente para incluir este novo aplicativo. Encontre o arquivo em:
    • Linux: <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/server.xml
    • Windows: <WorklightInstallDirectory>\WAS85liberty-server\server\wlp\usr\servers\worklightServer\server.xml
  15. Depois da declaração do aplicativo applicationcenter, adicione a nova tag do aplicativo mostrada na Listagem 14.
    Listagem 14. Adicionando um aplicativo ao 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. O servidor de perfil Liberty agora deve estar totalmente configurado para manipular o código do lado do cliente que você desenvolverá na próxima seção. Navegue para <WorklightInstallDirectory>/server/wlp/bin e depois execute este comando para iniciar o servidor:
    • Linux: sudo ./server start worklightServer
    • Windows: server.bat start worklightServer
  17. Acesse o console do Worklight em http://host.domain.com:9080/SSODemo/console/.

Configurar o aplicativo do lado do cliente

Agora que o arquivo WAR do servidor foi criado, algumas mudanças precisam ser feitas para que o aplicativo Worklight compile adequadamente no ambiente de desenvolvimento. Isso ocorre porque nem todos os pacotes são compilados, a menos que o aplicativo seja implementado com sucesso no servidor Jetty interno, o que não tem as classes do WebSphere necessárias para o login e, portanto, falha.

  1. Retorne para o arquivo worklight.properties e comente novamente todas as linhas modificadas na Listagem 7 de modo que se pareça com a Listagem 15.
    Listagem 15. Propriedades do servidor 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. Acesse authenticationConfig.xml e comente novamente para as seções do websphere que tiveram os comentários removidos anteriormente, como mostram as Listagens 16 e 17.
    Listagem 16. Domínio de segurança para o 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-->
    Listagem 17. Módulo de login para o WebSphere
    <!-- For websphere --> 
    <!--loginModule name="WASLTPAModule"> 
        <className>com.worklight.core.auth.ext.WebSphereLoginModule</className> 
    </loginModule-->
  3. Adicione um domínio e módulo de login falsos, como mostram as Listagens 18 e 19.
    Listagem 18. Adicionando um domínio falso WASLTPA
    <realm loginModule="WASLTPAModule" name="WASLTPARealm">
        <className>com.worklight.core.auth.ext.FormBasedAuthenticator</className>
    </realm>
    Listagem 19. Adicionando um módulo de login WASLTPA falso
    <loginModule name="WASLTPAModule">
    <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className>
    </loginModule>

    Alterar os domínios de segurança usados exigiria seguir as seções acima sobre a criação do arquivo WAR novamente, e então seguir outra vez estas últimas etapas para reverter os módulos do WebSphere depois de ter concluído.
  4. Adicione o HTML requerido para o aplicativo: SSODemo/apps/SSODemoApp/common/SSODemoApp.html. Altere o corpo do HTML para consistir no segmento de código mostrado na Listagem 20.
    Listagem 20. HTML do corpo de SSODemoApp.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>

    Isso adiciona duas seções ao corpo: uma área de conteúdo e uma área de autenticação. Atualmente, a área de conteúdo é simplesmente um IFrame que abrirá a página do portal depois de autenticado para o Worklight, mostrando que o SSO funcionou.

    Além disso, isso adicionou a tag do script para js/challengeResponse.js, que é um novo arquivo a ser criado que manipula o aspecto do lado do cliente da necessidade de manipular logins. Esse código está disponível para download e é amplamente baseado no manipulador de desafio criado na Autenticação baseada em formulário do Módulo 20.1, com algumas modificações para permitir verificar o cache criptografado para o login armazenado para acomodar autenticação automática. Se nenhum login for encontrado, então permite ao usuário efetuar login e armazena as informações para uso posterior para a autenticação automática. A Figura 10 mostra onde o arquivo challengeResponse.js estaria localizado.

    Figura 10. Localização do challengeResponse.js

    Quando o desafio de segurança é detectado e enviado para a função handleChallenge nesse arquivo challengeResponse.js, ele chama o indicador de ocupado para informar ao usuário de que o processamento está ocorrendo enquanto o cache criptografado é aberto para verificar as credenciais. O cache criptografado funciona totalmente por meio de chamadas assíncronas com manipuladores de retorno de chamada. Isso significa que cada verificação precisa ocorrer dentro desses retornos de chamada. Se tanto o nome de usuário quando a senha tiverem valores definidos no cache criptografado, então ele cria um envio de formulário para essas informações para o efetuar o login do usuário. Se um login não for encontrado, ele mostra o corpo de autenticação de modo que o usuário possa digitar as informações manualmente e efetuar login, com as credenciais agora sendo armazenadas para uso futuro quando o usuário clicar em enviar.

    Quando o login estiver concluído, o corpo do aplicativo pode ser mostrado junto com a origem do IFrames alterada para carregar o seu portal. O portal é carregado após login bem-sucedido; caso contrário, ele carregaria sem os tokens LTPA adequados para SSO, uma vez que a autenticação não concluiu no carregamento da página e esses desafios de autenticação são realizados por meio de XHR e não carregamentos de página completos.

  5. Depois de terminar de adicionar o arquivo challengeResponse.js (e atualizar para o nome do domínio e a url do portal corretos, por exemplo, "WASLTPARealm"), clique com o botão direito no ambiente Android e selecione Run As > Build All and Deploy para criar um novo arquivo wlapp para implementar no servidor Worklight. Abra o console do Worklight para o seu servidor http://worklight.domain.com:9080/SSODemo/console/ e depois escolha o arquivo no topo em que há a opção de implementar o aplicativo ou adaptador, e navegue para o espaço de trabalho do Worklight SSODemo. Na pasta da categoria, haverá um arquivo SSODemoApp-all.wlapp. Escolha esse arquivo e então Submit . O aplicativo agora deve estar implementado e aparecerá como na Figura 11.
    Figura 11. Aplicativo SSODemo implementado
  6. De volta ao ambiente de desenvolvimento, encontre o projeto que o ambiente Android adicionou, chamado SSODemoSSODemoAppAndroid. Clique com o botão direito do mouse e selecione Run As > Android Application.
  7. Quando o emulador ou dispositivo físico tiver carregado o aplicativo, um painel de login deve ser exibido. Faça o login utilizando um usuário do LDAP. A página inicial do seu portal deve efetuar login como esse mesmo usuário do LDAP. Quando o aplicativo for fechado e depois reaberto, você deve observar que o login do usuário é feito automaticamente.

Opções de topologia

Há opções de topologia do servidor a considerar ao planejar a implementação do Worklight e do WebSphere Portal. Um servidor proxy ou servidor HTTP pode ser necessário para o IBM Worklight Server e o WebSphere Portal. Um servidor proxy ou servidor HTML será necessário para implementar essa amostra quando os servidores não estiverem no mesmo sistema e você precisar ter uma URL (home de host comum para o WebSphere Portal e o Worklight) compartilhada com o usuário. O módulo de educação 45 do Worklight discute como usar um website remoto, como um hospedado no servidor do WebSphere Portal.

Além disso, o objetivo principal desta instância do servidor é agir como um substituto que pode encaminhar solicitações para agrupamentos de servidores de backend usando regras de roteamento e esquemas de balanceamento de carga. Tanto um servidor HTTP configurado com o plug-in HTTP quanto o servidor proxy do WebSphere Application Server pode ser usado para carregar solicitações de balanceamento de carga sendo atendidas pelos WebSphere Application Servers, agrupamentos ou servidores da web.

Se for necessário configurar um servidor da web (plug-in) com o perfil Liberty do WebSphere Application Server para rotear através de vários hosts, consulte o documento do Centro de Informações em Configurando um plug-in do servidor da web para o perfil Liberty.

Há diferenças entre usar um proxy e um plug-in HTTP, e para aprender as vantagens de cada solução, veja o artigo Proxy server versus the HTTP plug-in - Choosing the best WebSphere Application Server workload management option.

Para mais informações sobre instalar e configurar um proxy ou plug-in do servidor da web, veja estes recursos:


Conclusão

Este artigo descreveu como criar um aplicativo Worklight híbrido capaz de efetuar automaticamente o login de usuário e usar conexão única para permitir que esse usuário acesse o servidor WebSphere Portal sem exigir login adicional. Isso habilita a conveniência a que muitos usuários móveis estão acostumados em que a conta é acessada e usada facilmente ao abrir o aplicativo.

Possíveis maneiras de expandir esse exercício seria adicionar a habilidade de o usuário remover suas credenciais para poder usar um login diferente. Isso poderia ser feito simplesmente removendo os valores do cache criptografado sob solicitação do usuário e recarregando a página, acionando um novo login. Outra área seria detectar se o login de um usuário não é mais válido devido à mensagem de erro retornada mediante falha do login e remover os valores do cache para que o usuário possa conectar-se novamente com novos valores.


Download

DescriçãoNomeTamanho
Sample applicationPart3-SSODemo.zip46 KB

Recursos

Aprender

Obter produtos e tecnologias

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational, Desenvolvimento móvel
ArticleID=851520
ArticleTitle=Proporcione uma Experiência da Web Móvel Excepcional Usando o WebSphere Portal e o IBM Worklight V5.0, Parte 3: Implementando conexão única automática com Worklight e WebSphere Portal
publish-date=11262013