JBoss Video’s Channel en YouTube

Gente, para los que no sepan todavia, hay un canal de JBoss donde publican distintos eventos donde la empresa va participando. Ultimamente han agregado al canal los videos de la JavaOne 09, donde tenian un stand chiquito, pero vistoso y daban mini charlas sobre los distintos proyectos.

Les dejo la URL y luego trateremos de embeber el canal en la pagina del JBug.

http://www.youtube.com/user/JBossVideo

Saludos

Lanzamiento de JBug Argentina

Los invito a visitar y ser parte de esta iniciativa que intenta conformar una comunidad activa de profesionales con conocimientos en JBoss. Donde la meta es compartir intereses, gustos y conocimientos sobre las herramientas y middleware que JBoss propone.
Si ya tenes un blog o has escrito artículos sobre tecnologías propuestas por JBoss, contactate con el grupo de usuarios de JBoss y hagamos juntos crecer esta comunidad de habla hispana.

JBoss User Group Argentina

http://www.jbug.com.ar

Algunos Conceptos de JBossSSO

Los siguiente son conceptos que se iran refinando con mi entendimiento en el tema:
SSOTokenManager extiende de ValveBase.. es decir que ejecuta su metodo invoke cada vez que se hace un request.. Y como su documentacion dice intercepta todos los request en busca de la presencia de un SSOToken domain cookie..
Si el usuario se encuentra logueado (EL principal esta seteado) y la cookie no existe, crea una para el resto de la session.

SSOAutoLogin es un autenticador de tipo form que intercepta los request y busca la presencia de un SSOTOken domain cookie. Si existe la cookie se procesa y el pricipal es generado resultando en un Autologin. SSOAutoLogin Tambien exitiende de ValveBase

Si SSOAutologin no encuentra la cookie entonces se procede al metodo de autenticacion normal. Llevada acabo por la clase UsernameAndPasswordLoginModule que exitiende de UsernamePasswordLoginModule. Y esta es la encargada de soportar la autenticacion mediante username y password.

Esto esta definido en el web-inf de la aplicacion web en el archivo context.xml

Vamos a ver el flujo normal de las Valves en el camino del primer request a nuestra aplicacion de prueba:

1) SSOFederationRouter:

• Levanta la lista de partners  (usa un metodo llamado lookupPartners(request))
  • Este metodo agarra el nombre del server que se encuentra en el request y el puerto y busca la lista de partners en /federate/partners la cual parsea a continuacion, ya que este devuelve el XML de partners que tiene todos los partners  que estan en el archivo de configuracion llamado: server.cfg.xml dentro del federation-server.sar/conf/. Solamente trae los partners, es decir los distintos federation server que hay configurados. por lo tanto se ven de la forma: http://node1.jboss.com:8443/federate y http://node1.jboss.org:8443/federate
• Busca una variable dentro del request llamada referer y luego si la encuentra … TODO
• Continua con la cadena de Valves

2) SSOAutoLogOut

• Busca la session de SSOSession y si no encuentra ninguna crea un objeto SSOSession Nuevo (metodo SSOSession.getSSOSession())
• Luego con la clase auxiliar SSOUtil va a buscar un token SSO en el request. Este token lo busca en las cookies (metodo SSOUtil.getSSOToken())
• Si no encuentra el token pasa al siguiente valve en la cadena
• Si encuentra el token pone en true la flag llamada ssoCookieFound y continua la ejecucion en la siguiente cadena

3) SSOTokenManager

• Va a buscar el token con la clase SSOUtil.
• Va a buscar la cookie con Tool.isCookieFound()
• Va a buscar si estamos en el medio del proceso de LogOut mediante la busqueda de un cookie llamada LOGOUT_TOKEN
• Va a buscar una SSOSession y si no la encuentra crea una nueva
• Pregunta si el usuario esta loggeado y la cookie no se ha procesado para realizar el login automatico y setea un flag para que no se realicen autologins
• Si la cookie no se encuentra le pone un null a SSOSession.setTurOff
• Continua con el siguiente valve en la ejecucion a pesar de tener codigo todavia para ejecutar.

4) SSOAutoLogin

• Va a buscar una session y si no la encuentra crea una nueva SSOSession
• BUsco en la session que tengo tiene en la propiedad getTurnOff null tengo que realizar SSO (performSSO=true)
• Si performSSO llamamos al metodo performSSO(request,response)
  • Este metodo va y busca un token llamado SSO_SECURE_TOKEN
  • Si encuentra este token lo valida y setea el flag de que encontro la cookie
  • en caso de no ser valido fueza el logout
  • Si la cookie se encontro el flag fue seteado en true
    • Setea los atrivbutos SSO_USERNAME con el usuario obtenido del Principal igualmente con el SSO_PASSWORD
    • Ejecuta el autologin (metodo ssoLogin(request,response,config))
    • Si este metodo devuelve true, setea el principal en la SSOSession
  • Si la cookie no se encontro devuelve false
• Llamamos a la siguiente Valve en la cadena, si se realizo el autologin solamente va a pasar al siguiente????????????????
• Sino se realizo el SSOPerformed:
  • Como no se ejecuto el SSO ejecutar authentication mediante FORM

Una vez llegado al final de la ejecucion del Valve numero 4 en este caso SSOAutoLogin la cadena vuelve por el Valve numero 3 llamado SSOTokenManager a ejecutar el codigo que sigue a continuacion:

3) SSOTokenManager:

• Trata de obtener el principal, si lo encuentra pregunta si no se encontro la cookie, de cumplirse que tenemos un principal y no la cookie
  • Obtiene del dominio y creo que genera una cookie o manda un mensaje con saml para uqe se genere
• Si el principal es null , verifica si existe la cookie borra/limpia el token ya que no deberia existir

2) SSOAutoLogout: no hace nada ya habia terminado de ejecutar todo su codigo

1) SSOFederationRouter: no hace nada

Este recorrido en el request inicial lo va a hacer 4 veces ya que la pagina del test tiene 3 imagenes (es decir el 1 por el archivo html y 3 por las imagenes)

Los Valves tiene memoria por session de usuario, por lo tanto en el SSOFederationRouter no tienen que ir a buscar los partners todas las veces.

Ahora vamos a ver el request cuando nos authenticamos por primera vez a la aplicacion web, la idea es ver donde se crea el principal (en que request) y cuando afecta al flujo de la ejecucion de los Valves:

1) SSOFederationRouter:

• ahora si encuentra la variable Referer que indica la pagina de donde venimos: en este caso /secure/index.jsp
• Esta es la parte donde averigua  si de donde vengo estoy en un miembro de la federacion
• Como este es distinto de null, arma un objeto URL con el referer
• Luego compara si el referer domain es distinto al mydomain (ServerDomian) y verifica que dentro de los partners alguno tenga el dominio de referer. En caso de ser distintos setea un flag routing=true. En este caso se comparan los dominios y no los hosts, estos seria comparar jboss.com con jboss.org
• Si no se routea y son iguales los dominios (refererDomain y myDomain) entonces verifica si los hosts no son iguales (es decir el serverhost y el refererHost). En caso de ser iguales se setea el flag routing=true
• En el caso de que haya que routear hacemos:
  • TODO!!!!!!!!
• Continua la ejecucion con el siguiente Valve en la cadena

2) SSOAutoLogOut:

• Se comporta exactamente igual que cuando entramos por primera vez

3) SSOTokenManager

• Se comporta exactamente igual que cuando entramos por primera vez en el pagina

4) SSOAutoLogin

• Se comporta exactamente igual que cuando entramos por primera vez, pero cuando llamo al siguiente Valve en la cadena se encuentra con la “pagina” de autenticacion de JAAS.

En este punto llegamos a la  “pagina” que hace el login real por JAAS, (todavia no emprendemos la vuelta por la cadena de Valves), pero se realiza la Autenticacion y una vez que esto termina se vuelve por las Valves.

La autenticacion cae por medio de JAAS a la clase UsernameAndPasswordLoginModule.java al metodo initialize() el cual llama al metodo initialize() de la super clase que pertenece al paquete de javax.authenticacion.spi…… Este metodo levanta todas las opciones que definimos en el archivo: security-config.xml que define que LoginModule vamos a usar para un security-domain especifico (el cual especificamos en la aplicacion web de test)

Luego de esto vamos a pedir el userPassword con el metodo UsernameAndPasswordLoginModule.getUserPassword()

• Le pregunta al provider si el usuario existe pasandole el nombre de usuario (que supuestamente se seteo en el initialize del padre)
• Si existe se lee desde el provider el Identity (objeto Identity)
• Valida si el identity esta activo o no.
• Con esto obtiene el password encritapdo y lo devuelve

Luego vamos a buscar los Roles, para lo cual se realizan pasos muy similares a la obtencion del password. ver detalles.. itera sobre los grupos y sobre los roles definidos en el xml.

Ahora volvemos por la cadena hacia atras para devolverle el control al usuario junto con el response:

4) SSOAutoLogin:

• Preguntamos si se efectuo SSO, en este caso no.
• Pregunta si existe el principal y al parecer no se ha seteado todavia

3) SSOTokenManager:

• Va devuelta a buscar el princpial, pero le sigue dando null
• Pregunta si la cookie se encontro
• Continua

2) SSOAutoLogout: no hace nada

1) SSOFederationReouter: no hace nada

En esta etapa el security_check de JAAS termino exitoso y ahora trata de forwardear a la pagina de inicio de nuestra aplicacion

Ahora volvemos a tener otro ciclo de invocaciones a las Valves ya que ahora tenemos creados los principals.

1) SSOFederationRouter:

• El referer sigue siendo el mismo ya que la validacion de JAAS fue toda server side.. por lo tanto es: secure/index.jsp
• hace las comparaciones de dominios y hosts por lo tanto routing=false
• como no hay que hacer routing llama al siguiente Valve

2) SSOAutoLogout: hace lo mismo que en las rondas anteriores

3) SSOTokenManager:

• SSotoken=null, cookiefound=null, logoutinprogres=null
• SessionSSo nuevo
• Llama al siguiente valve

4) SSOAutoLogin:

• SSOSession nuevo
• No se hace SSO
• Llama a el siguiente Valve, no hay mas en la cadena
• Como No se ejecuto SSO vamos a buscar el principal , aca esta el principal (hay que tener cuidado si estamos debuggeando de que no se nos muera la session porque sino el principal se pone en null)
• Crea un SSOSession y le setea el principal

Volvemos por la cadena de valves:

3) SSOTokenManager:

• Vamos a buscar el principal, si no encontramos la cookie
• Crea la cookie a nivel de dominio (es decir para el dominio)
• Para esto hace Util.sednSSOToken()
  • Genera el token SAML
  • Crea la cookie TOKEN con el dominio y el path
  • Crea el cookie SECURE_TOKEN le agrega el TOKEN
  • Y esto se agrega el RESPONSE HTTP
• No esta la cookie

2) SSOAutoLogout: no hace nada

1) SSOFederationRouter: no hace nada

En este punto ya tenemos los TOKEN y SECURE_TOKEN Seteados

Para que las proximas llamadas lo utilicen.

JBoss SSO – tune in development

Pasos armados a partir de la wiki http://labs.jboss.com/wiki?windowstate=maximized

pero con los fuentes del proyecto y no con la distribucion binaria.. ademas no usamos el CR1 sino que el trunk. Para usar el CR1 cambiamos el repositorio a http://anonsvn.jboss.org/repos/jboss-sso/dev/tags/jboss-sso-1.0CR1/

Primero :

svn co http://anonsvn.jboss.org/repos/jboss-sso/dev/trunk/

Luego:

vi local.properties

y modificamos lo siguiente:

deploy.dir=default
jboss.home=/home/<user>/<jboss-4.2.2.GA>

Luego debemos tener instalado ant.. y todas sus librerias en /usr/share/ant/lib/

sino bajamos http://www.apache.org/dist/ant/binaries/apache-ant-1.7.0-bin.zip y copiamos todo el directorio lib a /usr/share/ant/lib/ y listo.

Tenemos que revisar que no tengamos una variable de entorno llamada JBOSS_HOME que apunte a otro jboss que no sea el que estamos usando

Con esto hecho ya podemos hacer..

en el directorio <jboss-sso>/components/build/

ant installSSO

Luego en el directorio ../jboss_federation_server/

ant deploy-exploded

y ahora debemos meternos con las configuraciones de red:

editamos el archivo /etc/hosts

nos deberia quedar algo asi

127.0.0.1 localhost node1.jboss.com
127.0.1.1 salaboy-desktop node1.jboss.org
127.0.2.1 node2.jboss.com

Una vez que tenemos esto.. debemos activar el ssl en el tomcat de jboss y generar un keystore local para que se use en la comunicacion ssl.

vamos a /home/salaboy/programas/jboss-4.2.2.GA/server/default/deploy/jboss-web.deployer/

y editamos el archivo server.xml

Descomentamos

<Connector port=”8443″ protocol=”HTTP/1.1″ SSLEnabled=”true”
maxThreads=”150″ scheme=”https” secure=”true”
clientAuth=”false” sslProtocol=”TLS” />

y agregamos la siguiente propiedad:

keystorePass=”<password>”

Las <password> que pongamos aca debera ser la misma usada al generar el keystore.

para generar el keystore vamos a nuestro home y hacemos lo siguiente:

salaboy@salaboy-desktop:~$ keytool -genkey -keyalg “RSA” -keystore keystore
Enter keystore password: jboss-sso
What is your first and last name?
[Unknown]: jboss
What is the name of your organizational unit?
[Unknown]: jboss
What is the name of your organization?
[Unknown]: jboss
What is the name of your City or Locality?
[Unknown]: baires
What is the name of your State or Province?
[Unknown]: capfed
What is the two-letter country code for this unit?
[Unknown]: AR
Is CN=jboss, OU=jboss, O=jboss, L=baires, ST=capfed, C=AR correct?
[no]: yes

Enter key password for <mykey>
(RETURN if same as keystore password):

Como podemos ver esto nos deja generado un archivo llamado keystore en nuestro home..

al que debemos renombrar a .keystore para ser encontrado por las configuraciones por defecto de “tomcat”. si queremos cambiar de nombre o de lugar este archivo de keystore debemos especificarlo en una propiedad del sever.xml llamada keystoreFile="<path al keysotre>"

Y ahora si.. ya podemos correr un jboss con:

./run.sh -c default -b node1.jboss.com

Y deberiamos copiar el default y correr otro similar bindeado a node1.jboss.org

y probar que funcione el ejemplo situado en http://node1.jboss.org:8080/test