Este año PRiSE ha querido apoyar al Club Waterpolo Dos Hermanas incorporándose como socio-colaborador para la temporada 2013-2014.
El primer equipo femenino del club es militante en la División de Honor. Por contra, el primer equipo masculino, este año se encuentra en la liga nacional de segunda, pero haciendo méritos partido tras partido para reincorporarse a la máxima categoría.
Esta temporada desde nuestro blog os seguiremos manteniendo informados de nuestras novedades y estudios, pero entre noticia y noticia ¡os tendremos al día sobre las batallas libradas en el agua!
Más información: http://www.waterpolo2h.com/noticiasm.asp?id=1656
Como ya comentamos en anteriores entradas, OAuth es un protocolo que permite que una aplicación externa pueda obtener acceso de forma limitada a un servicio web que puede ser de su misma propiedad o de un usuario externo.
En general, el acceso a los recursos se realiza mediante la presentación de un token de acceso, el cual ha sido obtenido por el cliente (la aplicación que realiza las peticiones a los recursos) presentando unas credenciales que representan la autorización del dueño del recurso (otro usuario o la misma aplicación).
En el RFC donde se define la nueva versión del protocolo, OAuth 2.0 (RFC 6749), podemos encontrar diferentes casos de uso, los cuales se denominan Grants.
Existen cuatro tipos predefinidos, aunque es posible implementar extensiones según unas directivas generales definidas en el estándar.
En esta entrada comentaremos los usos de cada uno de estos grants predefinidos, así como algunas de sus características principales.
- Authorization Code Grant: Este Grant define cómo el cliente redirecciona al dueño del recurso a un servidor de autorización que ofrecerá un código de autorización al cliente. Ese código de autorización será la credencial presentada por el cliente para obtener el token de acceso.
- Implicit Grant: El cliente obtiene un token de acceso directamente, sin existir un código de autorización. Suele utilizarse para librerías javascript. Uno de sus inconvenientes es que la validación del cliente se realiza mediante la URI a la que se enviará el token, por lo que al no incluir autenticación del cliente, la seguridad puede verse comprometida.
- Resource Owner password credentials: Las credenciales que se utilizan son el usuario y la contraseña del usuario. Este perfil está recomendado sólo para casos en los que existe un grado elevado de confianza entre el dueño del recurso y el cliente y cuando el cliente es capaz de obtener las credenciales del propietario del recurso.
- Client Credentials Grant: Este grant es utilizado en casos donde el objeto de la autorización se limita a los recursos protegidos bajo el control del cliente, es decir; cuando el cliente es el propietario del recurso (actuando en su nombre) o el cliente realiza una petición de acceso a recursos protegidos basados en una autorización previa establecida con el servidor de autorización.
Este mes estrenamos nueva versión de adAS 1.5.1.
Esta nueva versión se ha centrado en mejorar el rendimiento, la calidad y la usabilidad de adAS. Entre las mejoras que se han realizado, se encuentran las siguientes:
- Mejoras de rendimiento:Este aspecto es uno en los que más esfuerzo se ha invertido para esta nueva versión; disminuyendo de forma considerable los accesos a fuentes de datos y demás transacciones susceptibles de ser optimizadas. Como complemento a esta mejora, se ha incluido en adAS la capacidad de controlar por marcas de tiempo el rendimiento del SSO.
- Mayores posibilidades de personalización:Se ha ampliado la capacidad de configurar las plantillas de las páginas de autenticación/error de adAS de forma que se puedan adaptar en mejor medida a las necesidades de las organizaciones.
- Mejoras de usabilidad en la administración del SSO: Se ha incluido en la Herramienta de Administración de adAS, la funcionalidad de testear los atributos que se enviarán para los usuarios del SSO. Además de mejoras básicas de funcionamiento, se han refactorizado secciones de la administración, haciéndolas más usables y eficientes.
- Mejoras relacionadas con los logs: ahora es posible almacenarlos en bases de datos, además del almacenaje ya existente en archivos de texto y syslog. Además, se ha ampliado la información incluida en los logs para hacer la experiencia de gestión del SSO más cómoda.
Para más información acerca de estas mejoras y de otros bugs corregidos, consultar el archivo Release-Notes.txt
El otro día escuché en la radio una nota publicitaria sobre no sé que móvil que ya contaba con la última actualización de no sé que sistema operativo. Si, no me enteré nada bien del anuncio, pero será que me quedé congelada al escuchar «actualización» y «sistema operativo». Si ya hay que sufrir con ser «la informática de la familia» y tener que configurar la TDT cada vez que alguien toca sin querer cierto botón, ya sólo me faltaba asegurar que «el nuevo móvil que me han regalado y por fin tengo guasap» esté actualizado al nuevo y molón SO.
Al parecer, la sociedad se ha acostumbrado a palabras como smartphone, bases de datos, login, gigas, megas reales, sistema operativo, actualización de sistema operativo, etc. Y es que llevar ya un ordenador en el bolsillo que encima te permite llamar por télefono si tienes ganas de calentarte la oreja, ha acabado por familiarizar las TIC.
Dicho el preámbulo, el kit de este post llega ya. La familiaridad de las TIC ha hecho que «la informática de la familia que montó una empresa que se dedica a una cosa muy rara pero que le va muy bien» pueda ya medio explicar «esa cosa rara» y dejar las comillas olvidadas 
Hace tiempo, un buscador llamado Google que daba cuentas de correo empezó a comprar y añadir otros servicios. Algunos de estos servicios contaban ya con usuarios existentes a los que se respeta su acceso y los usuarios propios les permite el nuevo acceso con esas cuentas ya existentes para el correo. La lógica aplastante evitó que fuera necesario crear nuevos usuarios para esas nuevas aplicaciones. Si el usuario ya tenía una cuenta «google» debía acceder a esas webs con la misma cuenta.
Por lo tanto, gracias a querer una cuenta de correo puedo gestionar mis videos, mis fotos, mi red social, tener un blog, compartir archivos, guardar rutas de todo el mundo, etc. Y todo ello, autenticándome una única vez en uno de esos servicios. No hace falta que me dé de alta en ningún sitio, puedo acceder con mi cuenta.
En este sentido, se ha permitido que los usuarios estén acostumbrados a un acceso fácil a cualquier aplicación. Y con fácil me refiero a no tener que tener múltiples cuentas de usuario, no tener que poner sus credenciales en cada página web a la que se accede, reutilizar cuentas ya existentes, etc.
Para contar con ese escenario es necesario que todos esos servicios formen parte de un SSO (Single Sing On), dónde estos servicios o páginas web se denominan SP (Service Provider) y gracias a un protocolo de comunicación (SAML, CAS, PAPI, uno propio, etc) se integran con el IdP, que realiza la autenticación y atribución necesaria para que el usuario acceda a una determinada página web.
Dicho de una forma rápida. Y sin que se entienda nada. Pero si recuperamos el ejemplo de antes y no introducimos ningún término técnico, cualquier usuario de internet te dice (con más o menos gracia): «Ah, si! Es verdad que pongo mi correo y mi contraseña sólo en un sitio y ya todas las páginas web me enseñan mis cosas». Y preguntándoles por el trabajo, te suelen decir «Ufff… En el trabajo tengo 5 cuentas de usuario diferente para 4 cosas, porque hay una web que tengo dos usuarios diferentes según lo que quiera hacer».
Y es que en el mundo laboral el SSO aún no ha encontrado su lugar. Hay que aclarar que contar con las mismas cuentas y contraseñas en los diferentes servicios no es tener un SSO.
Desde PRiSE ayudamos a dar ese paso de inmersión del SSO en cualquier organización. Si ya disfrutas de las ventajas de un SSO en tu tiempo de ocio sin ser consciente, ¿por qué no lo aprovechas también en tu profesión?
Contamos con muchos casos de éxito de implantación de SSO, integrando aplicaciones de múltiples tecnologías en infraestructuras diversas. ¡Ponte en contacto con nosotros!
Y recogiendo por última vez el ejemplo de Google (válido también para Microsoft), logramos que el SSO de tu empresa pueda comunicarse sin problemas con el SSO de Google, integrando así todos los servicios de éste con los de tu empresa bajo una única cuenta para cada uno de tus usuarios.