Introducción

Este artículo describe cómo configurar una aplicación híbrida de IBM Worklight que automáticamente registre a un usuario al inicio a un servidor que ha sido configurado con inicio de sesión único (SSO) y que tiene un servidor de IBM WebSphere Portal en el mismo host. Tener los servidores configurados con SSO permite a los usuarios simplemente iniciar sesión una vez en el servidor de Worklight y después ser automáticamente autenticados en sus otros servidores en el mismo host.

Muchas aplicaciones móviles también ofrecen la habilitad de almacenar credenciales de usuario de forma que puede simplemente abrir la aplicación y ver esta información. Para añadir esto a la aplicación de muestra, puede implementar el caché cifrado desde Worklight para almacenar la información de inicio de sesión del usuario para futuros intentos de inicio de sesión. Esto permite a los usuarios abrir la aplicación y tener iniciada la sesión en sus cuentas en servidores de Worklight y WebSphere Portal.

Requisitos previos

Este artículo utiliza WebSphere Portal V8 y Worklight V5.0.0.3. Aunque WebSphere Portal es utilizado aquí, cualquier servidor que soporte SSO mediante un registro de usuarios de LDAP y autenticación de token de LTPA debe ser compatible con la configuración correcta de esos valores.

Antes de continuar con este ejercicio, asegúrese de tener:

• Un servidor de LDAP instalado y en ejecución.
• El servidor de WebSphere Portal V8 instalado y en ejecución.
• IBM Worklight Server instalado utilizando el perfil predeterminado Liberty y la base de datos de Derby.

Ya que configurará SSO entre un servidor de perfil Liberty ejecutando Worklight y un servidor de WebSphere Portal, ambos servidores necesitan ser configurados para utilizar el mismo registro de usuario, compartir claves de LTPA y estar configurados para utilizar un dominio específico para que el SSO funcione.

Volver arriba

Configure el servidor de perfil Liberty

Después de instalar Worklight Server con el perfil predeterminado Liberty y la base de datos de Derby, el servidor necesita ser configurado para utilizar el servidor de LDAP. El perfil Liberty maneja la configuración mediante un conjunto de valores predeterminados que utiliza a menos que especifique otra cosa dentro del archivo server.xml. Dependiendo de si está utilizando Linux® o Windows®, este archivo está ubicado en:

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

Realice estos cambios dentro del archivo server.xml:

1. Cambie el nombre de la cookie JSESSION de forma que no esté en conflicto con el servidor de WebSphere Portal. Para hacer esto, añada la etiqueta XML httpSession después de cerrar la etiqueta httpEndpoint con el atributo de nombre de cookie establecido como se muestra en el Listado 1.
   
   Listado 1. Cambio de nombre 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. Elimine el registro de usuario predeterminado instalado. El servidor tendrá errores con múltiples registros de usuario activos. Ubique el segmento basicRegistry, mostrado en el Listado 2, y elimínelo.
   
   Listado 2. Entrada de registro básico
   

   <!-- 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 continuación, añadirá el registro de usuario de LDAP. El Listado 3 muestra un ejemplo de la configuración utilizada; sin embargo, la información en negritas necesitará cambiar dependiendo de cómo configure su LDAP. El perfil Liberty también tiene filtros adicionales, tales como userFilter solo para otros aspectos del servidor de LDAP, como los grupos. Adicionalmente, si su servidor de LDAP está configurado para utilizar SSL, existen opciones que puede utilizar para configurar eso también. Vea el Centro de Información para obtener más información sobre las opciones de configuración de server.xml o conectarse a un servidor de LDAP que esté utilizando SSL.
   
   Listado 3. XML de configuración de 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. Cambie la seguridad del servidor para utilizar cookies de SSO que estén configuradas para el dominio apropiado, que puede ser configurado directamente después de la entrada ldapRegistry. Sustituya el nombre de dominio en negrita a continuación por el dominio en el que estará trabajando:

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

5. Para volver a verificar la configuración y generar una clave de LDAP, inicie el servidor. Navegue hacia <WorklightInstallDirectory>/server/wlp/bin y después ejecute este comando para iniciar el servidor:
   • Linux: sudo ./server start worklightServer
   • Windows: server.bat start worklightServer
   Verifique el archivo de registro para asegurarse que el servidor se inició con éxito con sus configuraciones:
   • Linux: <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/logs/console.log
   • Windows: <WorklightInstallDirectory>\WAS85liberty-server\server\wlp\usr\servers\worklightServer\logs\console.log
6. Detenga el servidor:
   • Linux: sudo ./server stop worklightServer
   • Windows: server.bat stop worklightServer

Volver arriba

Configure el servidor de WebSphere Portal

1. Para configurar el LDAP del servidor de WebSphere Portal, creará un archivo ldapConfig.properties con algo de la información de configuración mostrada en el Listado 4, con base en sus valores de LDAP. Necesitará sustituir los valores para la mayoría de estas propiedades con base en la configuración de su servidor. Los valores deben coincidir con lo que utilizó para la mayoría de la configuración del LDAP del servidor de perfil Liberty.
   
   Listado 4. Propiedades de LDAP de 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. Después de crear y configurar este archivo, muévalo a su máquina de WebSphere Portal y después ejecute las tareas ConfigEngine en el Listado 5a o 5b.
   
   Listado 5a. Tareas 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

   
   
   
   Listado 5b. Tareas 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 el servidor de portal y continúe con las tareas en los Listados 6a o 6b.
   
   Listado 6a. Tareas ConfigEngine, parte 2 (Linux)
   

   ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config ./ConfigEngine.sh wp-update-federated-ldap-attribute-config

   
   
   
   Listado 6b. Tareas ConfigEngine, parte 2 (Windows)
   

   ConfigEngine.bat wp-validate-federated-ldap-attribute-config ConfigEngine.bat wp-update-federated-ldap-attribute-config

   
   
4. Una vez que el LDAP se ha federado, es posible que su inicio de sesión de usuario se haya vuelto ambiguo si existe más de un usuario con el mismo inicio de sesión en el LDAP y en el portal. Para corregir esto, utilice un nombre completo de usuario para iniciar sesión. Abra en un navegador la consola de administración de WebSphere Application Server, inicie sesión y navegue hacia Security > Global Security > Web and SIP security > Single sign-on (SSO) (Figura 1).
   
   Figura 1. Mecanismos de autenticación y vencimiento
   
   
   
5. Asegúrese de que el nombre de dominio es el mismo que está utilizando con el archivo Liberty y establezca los nombres de cookie de LTPA como se muestra con el modo Interoperability activado. Una vez hecho esto, haga clic en OK y salve los cambios.
   
   Figura 2. Propiedades de inicio de sesión único (SSO)
   
   
   
6. Copie las claves de LTPA que están ubicadas en el servidor de Worklight a su máquina local, ya que necesitan ser importadas a WebSphere Portal. El archivo de claves de LTPA en el servidor de Worklight está ubicado en:
   • 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 continuación, en la consola de administración de WebSphere Application Server, navegue de regreso hacia Security > Global Security. En la página Global Security sobre la seguridad Web y de SIP, LTPA muestra la parte superior de la sección Authentication (Figura 1). Al fondo del formulario en esa página, escriba la contraseña WebAS, que es la predeterminada para la clave del perfil Liberty si está importándolo. Si está utilizando su propia clave, ingrese la contraseña apropiada. Para el nombre del archivo de clave completa, escriba la ruta y el nombre del archivo en el archivo ltpa.keys (Figura 3). Una vez hecho esto, haga clic en Import keys y salve los cambios de nuevo. .
   
   Figura 3. Seguridad global
   
   
   
8. Ahora reinicie el servidor de WebSphere Portal.

Volver arriba

Configure la aplicación de Worklight

Ahora puede crear su aplicación de Worklight al crear el archivo WAR para el servidor Liberty y la aplicación real del lado del cliente.

1. Abra el entorno de desarrollo de Worklight y Cree una nueva Aplicación Híbrida con el nombre de proyecto SSODemo y el nombre de aplicación SSODemoApp. Después añada un nuevo entorno de Android a este proyecto. Su área Project debe verse como la Figura 4.
   
   Figura 4. Carpetas de proyecto
   
   
   
2. Para configurar apropiadamente un archivo WAR para su servidor Liberty, primero necesita modificar worklightServerRootURL en application-description.xml mientras esté en la vista Design para señalar dónde estará el servidor de Worklight en su servidor de perfil Liberty, como http://host.domain.com:9080/SSODemo. Note que la ruta incluye el nombre del proyecto, ya que estará desplegando su archivo WAR de Worklight hacia esta ruta.
   
   Figura 5. URL de raíz del servidor
   
   
   
3. En SSODemo/server/conf/worklight.properties, desea remover los comentarios y cambiar los valores mostrados en el Listado 7.
   
   Listado 7. Propiedades del servidor de 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 el archivo y después abra SSODemo/server/conf/authenticationConfig.xml en la vista Source. Antes del elemento <realms>, añada el XML <securityTests> como se muestra en el Listado 8.
   
   Listado 8. Pruebas de seguridad
   

   <securityTests> <mobileSecurityTest name="mobileTests"> <testDeviceId provisioningType="none" /> <testUser realm="WASLTPARealm" /> </mobileSecurityTest> <customSecurityTest name="WASLTPARealmTests"> <test realm="WASLTPARealm" isInternalUserID="true"/> </customSecurityTest> </securityTests>

   
   
5. Remueva los comentarios del dominio de seguridad mostrado en el Listado 9 que está etiquetado For websphere.
   
   Listado 9. Dominio de seguridad 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. Elimine los comentarios del módulo de inicio de sesión For websphere (Listado 10).
   
   Listado 10. Módulo de inicio de sesión para WebSphere
   

   <!-- For websphere --> <loginModule name="WASLTPAModule"> <className>com.worklight.core.auth.ext.WebSphereLoginModule</className> </loginModule>

   
   
7. Regrese al archivo SSODemo/apps/SSODemoApp/application-descriptor.xml en la vista Design. En la aplicación principal, desea añadir una prueba de seguridad de WASLTPARealmTests en la sección Common (opcional) (Figura 6).
   
   Figura 6. Prueba de seguridad para la aplicación principal
   
   
   
8. En teléfonos y pizarras digitales de Android en Details, añada la Prueba de seguridad de mobileTests.
   
   Figura 7. Prueba de seguridad de Android
   
   
   
9. Salve el archivo y el archivo WAR es automáticamente generado en la carpeta bin. Copie el archivo WAR que fue creado en otra ubicación para edición. El archivo WAR está ubicado en: <workspace>/bin/SSODemo.war.
10. El archivo WAR necesita algunos ajustes para habilitar completamente la autenticación del servidor del perfil Liberty. Es necesario un login.html simple y un loginError.html para poner el archivo WAR. Cree estos archivos con el contenido mostrado en los Listados 11 y 12.
    
    Listado 11. Contenido del archivo 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>

    
    
    
    Listado 12. Contenido del archivo loginError.html
    

    <html> <head></head> <body> Login Error </body> </html>

    
    
11. Abra el archivo SSODemo.war con un gestor de archivos y añada estos dos archivos HTML en el directorio de nivel superior del WAR (Figura 8).
    
    Figura 8. login.html y loginError.html añadidos al archivo WAR
    
    
    
12. A continuación, navegue hacia la carpeta WEB-INF del WAR y edite el archivo web.xml, resaltado en la Figura 9, para incluir el XML en el Listado 13 al fondo a la derecha, antes de la etiqueta de cierre web-app.
    
    Figura 9. Ubicación de web.xml en el archivo WAR
    
    
    
    
    Listado 13. XML login-config de web.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. Suba este archivo WAR modificado a su servidor de perfil Liberty en el directorio <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/apps.
14. Modifique el server.xml del perfil Liberty para Worklight Server de nuevo para incluir esta nueva aplicación. Encuentre el archivo en:
    • Linux: <WorklightInstallDirectory>/server/wlp/usr/servers/worklightServer/server.xml
    • Windows: <WorklightInstallDirectory>\WAS85liberty-server\server\wlp\usr\servers\worklightServer\server.xml
15. Después de la declaración de la aplicación applicationcenter, añada la nueva etiqueta de aplicación mostrada en el Listado 14.
    
    Listado 14. Añadiendo la aplicación a 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. El servidor de perfil Liberty ahora debe estar completamente configurado para manejar el código del lado del cliente que desarrollará en la siguiente sección. Navegue hacia <WorklightInstallDirectory>/server/wlp/bin y después ejecute este comando para iniciar el servidor:
    • Linux: sudo ./server start worklightServer
    • Windows: server.bat start worklightServer
17. Vaya a la consola de Worklight en http://host.domain.com:9080/SSODemo/console/.

Volver arriba

Configure la aplicación del lado del cliente

Ahora que el archivo WAR del servidor está creado, se necesitan hacer algunos cambios para hacer que la aplicación de Worklight se compile apropiadamente en el entorno de desarrollo. Esto es porque no todos los paquetes son compilados a menos que la aplicación se despliegue con éxito en el servidor de Jetty interno, el cual no tiene las clases de WebSphere necesarias para inicio de sesión y por lo tanto falla.

1. Regrese al archivo worklight.properties y vuelva a comentar todas las líneas modificadas en el Listado 7, de forma que se vea como el Listado 15.
   
   Listado 15. Propiedades del servidor de 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. Vaya a authenticationConfig.xml y vuelva a comentar las secciones for websphere en las que se removieron los comentarios anteriormente, como se muestra en los Listados 16 y 17.
   
   Listado 16. Dominio de seguridad 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-->

   
   
   
   Listado 17. Módulo de inicio de sesión For WebSphere
   

   <!-- For websphere --> <!--loginModule name="WASLTPAModule"> <className>com.worklight.core.auth.ext.WebSphereLoginModule</className> </loginModule-->

   
   
3. Añada un dominio y un módulo de inicio de sesión falsos, como se muestra en los Listados 18 y 19.
   
   Listado 18. Añadiendo el dominio falso WASLTPA
   

   <realm loginModule="WASLTPAModule" name="WASLTPARealm"> <className>com.worklight.core.auth.ext.FormBasedAuthenticator</className> </realm>

   
   
   
   Listado 19. Añadiendo el módulo de inicio de sesión falso WASLTPA
   

   <loginModule name="WASLTPAModule"> <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className> </loginModule>

   
   Cambiar los dominios de seguridad utilizados requerirá seguir la sección anterior sobre la creación del archivo WAR de nuevo y después seguir estas últimas etapas para revertir los módulos de WebSphere una vez finalizados.
4. Añada el HTML necesario para la aplicación: SSODemo/apps/SSODemoApp/common/SSODemoApp.html. Cambie el cuerpo del HTML para que consista en el segmento de código mostrado en el Listado 20.
   
   Listado 20. HTML del cuerpo 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>

   
   Esto añade dos secciones al cuerpo: un área de contenido y un área de autenticación. Actualmente, el área de contenido es simplemente un IFrame que abrirá la página de portal una vez que sea autenticado en Worklight, mostrando que el SSO funcionó.

   Adicionalmente, esto añadió la etiqueta de script para js/challengeResponse.js, el cual es un nuevo archivo a ser creado que maneja el aspecto del lado del cliente de la necesidad de manejar inicios de sesión. Este código está disponible para descarga y se basa en gran medida en el manejador de retos creado en Module 20.1 Form-based Authentication, con algunas modificaciones para permitir la verificación del caché cifrado para el inicio de sesión almacenado para acomodar la autenticación automática. Si no se encuentra un inicio de sesión, entonces permite al usuario iniciar sesión y almacena la información para su uso posterior para la autenticación automática. La Figura 10 muestra dónde debe estar ubicado el archivo challengeResponse.js.

   
   
   Figura 10. Ubicación de challengeResponse.js
   
   
   

   Cuando se detecta un reto de seguridad y es enviado a la función handleChallenge en este archivo challengeResponse.js, llama al indicador ocupado para informar al usuario que el procesamiento está ocurriendo mientras el caché cifrado es abierto para verificar las credenciales. El caché cifrado funciona completamente mediante llamadas asíncronas con manejadores de devolución de llamada. Esto significa que cada verificación necesita suceder dentro de estas devoluciones de llamada. Si el nombre de usuario y la contraseña tienen valores establecidos en el caché cifrado, entonces crea un envío de formulario para esta información para que el usuario inicie sesión. Si no se encuentra un inicio de sesión, muestra el cuerpo de autenticación de forma que el usuario pueda escribir la información manualmente e iniciar sesión, con las credenciales ahora siendo almacenadas para su futuro uso cuando el usuario haga clic en submit.

   Cuando el inicio de sesión está completo, el cuerpo de aplicación puede ser mostrado junto con el origen de IFrames cambiado para cargar su portal. El portal es cargado después del inicio de sesión exitoso; de otra manera, se cargaría sin los tokens de LTPA apropiados para SSO, ya que la autenticación no se ha completado en la carga de página y estos retos de autenticación son realizados mediante XHR y no cargas de página completa.

5. Una vez que haya terminado de añadir el archivo challengeResponse.js, haga clic con el botón derecho en el entorno Android y seleccione Run As > Build All and Deploy para crear un nuevo archivo wlapp para desplegarlo en el servidor de Worklight. Abra la consola de Worklight para su servidor http://worklight.domain.com:9080/SSODemo/console/ y después elija el archivo en la parte superior donde tiene la opción para desplegar la aplicación o el adaptador y navegue hacia su espacio de trabajo de SSODemo de Worklight. En la carpeta bin, habrá un archivo SSODemoApp-all.wlapp. Elija este archivo y después envíelo . La aplicación ahora debe estar desplegada y aparecer como en la Figura 11.
   
   Figura 11. Aplicación SSODemo desplegada
   
   
   
6. De regreso en su entorno de desarrollo, encuentre el proyecto que el entorno de Android añadió, llamado SSODemoSSODemoAppAndroid. Haga clic con el botón derecho y seleccione Run As > Android Application.
7. Una vez que el emulador o dispositivo físico ha cargado la aplicación, un panel de inicio de sesión debe mostrarse. Inicie sesión utilizando un usuario del LDAP. La página frontal de su portal debe aparecer con inicio de sesión como ese mismo usuario de LDAP. Cuando una aplicación es cerrada y después se vuelve a abrir, debe ver que el usuario inicia sesión en forma automática.

Volver arriba

Conclusión

Este artículo describió cómo crear una aplicación híbrida de Worklight que es capaz de iniciar sesión automáticamente en un usuario y utilizar inicio de sesión único para permitir que el usuario acceda a su servidor de WebSphere Portal sin requerir un inicio de sesión adicional. Esto habilita una comodidad a la que muchos usuarios móviles están acostumbrados, en la que su cuenta es fácilmente accedida y utilizada al abrir la aplicación.

Una forma posible de ampliar este ejercicio sería añadir la capacidad para que el usuario elimine sus credenciales, de forma que pueda utilizar un inicio de sesión distinto. Esto podría realizarse simplemente eliminando los valores del caché cifrado cuando el usuario lo solicite y recargando la página, desencadenando un nuevo inicio de sesión. Otra área sería detectar si el inicio de sesión de un usuario ya no es válido debido al mensaje de error retornado después del fallo en el inicio de sesión y eliminar los valores de caché, de forma que el usuario pueda iniciar sesión de nuevo con nuevos valores.

Volver arriba

Descargar

Información sobre métodos de descarga

Recursos

Aprender

• Todos los artículos en esta serie
  
  
• IBM Mobile Foundation
  
  
• Información de producto de IBM Worklight
  
  
• Documentación del usuario de IBM Worklight
  
  
• Comenzar con IBM Worklight
  
  
• Información de producto de WebSphere Portal
  
  
• Documentación de Producto de IBM WebSphere Portal 8
  
  
• Desarrollar una Experiencia Web Excepcional
  
  
• Diseño Web Responsivo
  
  
• Capacitación de Android: Utilizando Dispositivos de Hardware
  
  
• Referencia de API y SPI de IBM WebSphere Portal 8
  
  
• Referencia de API de Apache Cordova
  
  
• Zona de desarrollo de IBM developerWorks Mobile
  
  
• Zona de IBM developerWorks WebSphere Portal
  
  
• IBM developerWorks WebSphere
  
  

Obtener los productos y tecnologías

• IBM Worklight Developer Edition 5.0
  
  
• Eclipse
  
  
• SDK de Android
  
  

Sobre el autor

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Introducción
• Configure el servidor de perfil Liberty
• Configure el servidor de WebSphere Portal
• Configure la aplicación de Worklight
• Configure la aplicación del lado del cliente
• Conclusión
• Descargar
• Recursos
• Sobre el autor
• Comentarios