En esta segunda (acontecida hoy) valoramos como Gartner nos puede ayudar a conseguir nuestro objetivo último (abrir canales de venta masivos). Gracias al buen hacer del interlocutor, rápidamente empezamos a hablar de las cosas que estamos haciendo y de las otras que necesitábamos para el objetivo final, hasta aquí todo correcto.

Llegados a este punto, hago una simple pregunta; ¿Cuál es el valor que Gartner aporta a la hora de poner en marcha un modelo comercial para nuestros productos?… aquí empieza el verdadero motivo del cual quiero hablaros, mi teoría del “no-mercado” (siempre desde mi punto de vista y con permiso de http://www.burbuja.info/inmobiliaria/burbuja-inmobiliaria/106395-aportacion-de-espana-a-teoria-economica-nomercado.html).

El no-mercado es algo completamente distinto del mercado: es un mecanismo para crear y mantener riqueza basado en el no-intercambio de bienes y servicios.

En el no-mercado hay no-vendedores y no-compradores. Su principal función es fijar no-precios de no-venta a los cuales los bienes y servicios no se venden.

Ejemplo de hoy… el sector inmobiliario, un no-mercado como una casa (no se vende un colín). Otro ejemplo, el software a medida (se vende poco y con muy poco margen).

En este punto la conversación tomó otros derroteros. El interlocutor hablaba de canales comerciales tradicionales y cuanto nos costaría sus servicios para conseguir abrir esos canales. Por otro lado, yo hablaba de nuevas formas de hacer negocio en el mundo del software (nuevas formas de distribución y de asociación empresarial).

Esta conversación empieza a ser recurrente en algunas de nuestras reuniones empresariales. El resumen de esta conversación es simple: tienes que vender a la antigua usanza, tienes que hacer las cosas como siempre y si no lo haces te estás confundiendo. Nosotros tenemos una respuesta preparada, si lo hago como antes estamos en el no-mercado ya que ningún cliente podrá pagar los productos o servicios al precio adecuado (costes, falta de financiación, etc…)

A los no-compradores les gustaría ser compradores, y estarían dispuestos a pagar el no-precio pedido por el no-vendedor; pero para ello necesitarían crédito, algo imposible desde que los bancos han comprendido de repente que la renta del no-comprador medio no alcanza ni de lejos lo necesario para devolver el crédito.

Este es el valor que este interlocutor de Gartner daba a sus servicios para conseguir vender nuestros productos. Básicamente nos quería vender la idea de que unos señor@s nos enseñarían el camino para vender en un cierto nicho a cambio de x€.

En ningún momento nos dijo que nuestro producto estuviera mal enfocado, que el mercado había cambiado, que los no-compradores no podrían comprar, vamos que en ningún momento nos habló de la nueva realidad empresarial en el mundo del software (el verdadero mercado).

Entiendo que en la primera toma de contacto es difícil acercar posturas a un nivel de detalle mayor, pero nunca puedes perder el norte que te trajo hasta aquí. Por lo que los cantos de sirena cantos son, no hacerlos caso es lo más recomendable si el sitio al que te acercan está lejos del nuevo mercado.

Bueno, lógicamente aquí cerramos la conversación (enfoques totalmente distintos a varios niveles). Hemos quedado pendientes de tener un nuevo contacto más adelante para ver como evoluciona nuestro proyecto y para ver posibles formas de acercamiento (espero que algo más adecuadas para el nuevo mercado).

La verdad es que estamos muy contentos por esta primera toma de contacto con una empresa del renombre de Gartner, es signo de que vamos por el buen camino (aunque tengamos aún mucho que recorrer). Por otro lado sentimos que ciertas empresas no entiendan la verdadera problemática del nuevo entorno económico y no se pongan a la altura de miras adecuada para conseguir los objetivos finales (encontrar un hueco en el nuevo mercado olvidando aquello que no funciona del no-mercado).

Nosotros seguiremos trabajando en la dirección que creemos adecuada, en la que creemos firmemente, la que nos motiva y nos hace sentir vivos. ¿Y tú?

Blog | Tienda

Estudio de mercado

Mientras este primer ejemplar llega a mis manos sigo valorando otras opciones de mini PC para ARM o incluso x86 para un prototipo de un proyecto que tengo en marcha (software acabado). Hay varias opciones interesantes, pero de momento poco que añadir a la cesta ya que la posible competencia de la famosa Frambuesa está lejos en precio.

Lo realmente importante de la entrada de este mini PC es que marca el camino para los muchos que irán apareciendo durante este año y que podremos adquirir de forma masiva a precios reducidos (entre 30€ y 120€).

Con estos PC’s podremos desplegar aplicaciones empresariales a muy bajo coste para nuestros clientes.

Podrán disfrutar de una caja con todo nuestro software empresarial a un precio realmente competitivo.

Mini PC’s ARM:

Raspberri Pi (25/50€)
Hay que añadir caja, transformador, tarjeta de memoria y wifi.
http://www.raspberrypi.org/

FXI Cotton Candy (189€ en Preorder)
Interesante y potente, pero fuera de precio.
http://store.cstick.com/

Mele A1000 (60/85€)
Potente y con todo lo necesario incluido.
http://www.dealextreme.com/p/mele-1080p-android-2-3-internet-tv-set-top-box-w-wifi-optical-3-x-usb-hdmi-av-lan-sd-119913
http://www.cnx-software.com/2012/04/08/mele-a1000-android-2-3-stb-unboxing-and-review/

Mini PC’s x86:

Zaapa ZMC7 Barebone (86€)
Es un barebone, por lo que hay que añadir memoria ram y disco duro
http://www.pccomponentes.com/zaapa_zmc7_barebone.html

Intel NUC (Precio por concretar)
Un PC i3 o i5 en una caja de 10x10cm.
http://www.electronista.com/articles/12/04/30/next.unit.of.computing.is.smaller.than.miniitx/

Blog | Tienda

Mini PC

Las cadenas de escape, permiten introducir dentro de una cadena caracteres especiales como saltos de líneas, acentos, tabulaciones, etc.

Las cadenas de escape más conocidas son:

• \n: Salto de línea
• \r: Retorno de carro
• \t: Tabulación horizontal
• \v: Tabulación vertical
• \’: Comilla simple
• \”: Comilla doble
• \\: Barra invertida
• \xdd: Carácter especial especificado mediante dos dígitos hexadecimales dd

El último caso, el del carácter especial (\xdd), es el que nos permite, entre otras cosas, insertar letras acentuadas o la letra ñ.

Lo único que necesitamos para ponerlo en práctica es una tabla con el juego de caracteres unicode. Veamos la tabla para latin:

Un ejemplillo:

function ErrorEnFecha() {
alert("Atenci\xf3n: El a\xf1o de nacimiento es menor de 10.");
}

Blog | Tienda

Caracteres especiales en JavaScript

Esta nueva versión facilitará el renderizado 3D en QML mediante OpenGL.

También está disponible la versión 1.0 de Qt 3D para Qt 4.8.1 (solo compatible en ciertos S.O.)

¿Qué pasa con Qt5?

Ahí es donde está el meollo de la cuestión, Qt5 incorpora QtQuick 2.0 con un motor de renderizado muy mejorado, con soporte OpenGL y con Qt 3D.

¿Y esto que tiene que ver con Velneo?

Sencillo, pronto Velneo dará soporte oficial en V7.9 a QML 1.0  (Qt 4.7.2).

Después de este lanzamiento probablemente empezarán a trabajar en 4.8.1 (o tal vez esperen algo más 4.8.2?). Al tiempo empezarán con la migración a Qt5 (esta tarea no será sencilla, aunque algo me dice que será menos traumática que de Qt3 a Qt4).

Por último, y según evolucione el roadmap de Qt 5 podrán incorporar todas estas tecnologías (puede pasar más de un año para que sea una realidad ya que Qt 5 aún está en versión Alpha Qt5)

Se imaginan una aplicación Velneo V7 (por ejemplo para arquitectura o gestión hospitalaria) que integre este tipo de tecnologías… Con Qt5 será posible y de una forma totalmente declarativa, por lo que es muy probable que Velneo también las integre.

No lo dudes… Aprende QML

Blog | Tienda

Qt 3D y Qt5 – Qt4

Melmeti:

Reuters ha confirmado que el sistema operativo está cada vez más cerca, aunque aún no hay fechas específicas o plazos.

http://gadgetsteria.com/2012/03/09/reuters-nokias-meltemi-s40-successor-edging-closer-to-release/

http://realnorth.net/blog/meltemi-es-real/

Además todo apunta a que vendrá integrado con Qt por lo que pondrá a los programadores Qt/QML en predisposición de abordar mercados emergentes.

http://nokia.hdblog.it/2012/03/21/qt-verra-integrato-nel-sistema-operativo-meltemi/

Android:

Los resultados de la versión actual son esperanzadores, aunque el proyecto se encuentra aún en la versión alpha 3 update 4 (18 Feb 20) por lo que le queda bastante para ser totalmente funcional.

http://sourceforge.net/p/necessitas/home/necessitas/

RIM:

BlackBerry 10 basado en QNX al igual que PlayBook OS soportarán Qt.

http://www.xatakamovil.com/blackberry/blackberry-10-soportara-qt-desarrolladores-de-nokia-rim-os-tiende-la-mano

Otros muchos:

Canonical, KDE, Raspberry Pi y otros proyectos open source pueden darle otro pequeño empujón a este maravilloso framework que es Qt.

Vamos… que aún quedan esperanzas…

Blog | Tienda

Aplicaciones Nokia

PaaSOS ERP es uno de los productos empresariales de PaaSOS, le permitirá gestionar el ciclo completo de compra/venta de su empresa.

PaaSOS ERP es un sistema de gestión empresarial colaborativa que integra muchos de los aspectos de distribución y comercialización relacionados con empresas que producción de bienes o servicios.

Su fuerte integración con nuestras tecnologías colaborativas le permitirá adaptarlo fácilmente a sus necesidades.

Su funcionamiento es simple e intuitivo e integra muchas funcionalidades empresariales que le facilitan su puesta en funcionamiento y su fácil entendimiento.

PaaSOS ERP está especialmente recomendado para pymes, micropymes y trabajadores autónomos debido a su sencillez y su bajo coste.

También es recomendable para empresas que desean crear sus soluciones empresariales adaptadas a bajo coste.

Blog | Tienda

Programa de facturación

Veamos como empieza el año para nosotros (en lo tecnológico y comunidad. Dejo el tema negocio para más adelante).

Velneo V7

Hablemos de Velneo, hablemos de V7.

Novedades

• ¿Será el año de Android?. Si, todo apunta a que Android ocupará un hueco importante. Veremos también como Windows Phone 7 se incorpora al mercado de Smartphones intenta hacer lo propio.
• ¿El cliente de Android está maduro?. No, aún le falta un par de releases más. Hay aún problemas importantes en el port de Android de Qt, por lo que estos problemas serán arrastrados a nuestra plataforma.
• QML y JavaScript seguramente serán lanzados en Febrero. ¿Será bueno para Velneo la apertura?. Si, pero…
• ¿Tendremos que aprender mucho?. La comunidad necesitará bastante trabajo y dedicación para aprovechar QML. JavaScript será más sencillo, pero abre un mundo de posibilidades que habrá que explorar, por lo que su aprovechamiento será lento.
• ¿No será demasiado complicado?. Lo será, habrá muchas cosas nuevas.
• ¿Qué cosas podré hacer?. Consumo de servicios web, aplicaciones para tablet’s, más dinamismo en los UI, API en JavaScript para manejar el motor y el UI…

Este año será muy divertido en lo tecnológico, es lo que tocaba.

Habrá algunas novedades importantes: QML, vJavaScript, SuperRejilla, vDebugger y Android.

Madurez de la plataforma

La verdad es que existe un descontento generalizado (especialmente en la comunidad v6 que no se introdujo en V7) que evidencia ciertas carencias o problemas de la plataforma.

Como sabéis hemos sido abanderados en la adopción de V7, conocemos en detalle las versiones precedentes v6 y otros entornos (especialmente .NET). Nuestra percepción es que la plataforma es madura en ciertos aspectos y es inmadura en otros. Por lo que la percepción de la madurez de la plataforma dependerá de la óptica y enfoque.

Estado del arte

• Desarrollo rápido. Con V7 desarrollarás rápido, muy rápido. Eso sí te costará empezar a hacerlo ya que V7 no es v6, es otra cosa.
• Curva de aprendizaje media-baja. V7 es complejo respecto a su prima v6, pero es mucho menos complejo que .NET. La curva de aprendizaje es media, tardarás entre uno y dos años en dominar V7 (.NET se tarda de dos a tres años).
• Ejecución multiplataforma. Es una de nuestras apuestas. A día de hoy la compatibilidad en Win/Lin/MacOSX es muy alta. La multiplataforma es un factor de peso en la elección ya que el mercado está explosivo, se introducen continuamente nuevos S.O. y por lo tanto hay que estar preparados para cualquier futuro tecnológico (nadie puede concretar como será el mercado dentro de cinco años).
• SaaS/PaaS. Otra de nuestras apuestas. V7 es un gran producto para entornos colaborativos, colaborar en el desarrollo de aplicaciones es una de las claves del presente y futuro. Poder distribuir, desarrollar y administrar nuestros sistemas de esta forma es otro factor de peso en la elección.
• Base de datos. La base de datos de Velneo V7 es una base de datos adecuada para entornos empresariales pequeños-medianos. Es estable y robusta aunque más lenta que v6 en ciertos escenarios.
• Qt. El crecimiento de Qt desde que Nokia abandonó Meego es confuso. La nueva versión 4.8 muestra la dirección que tomará Qt, mayor apertura, más plataformas soportadas, gobierno abierto… Pero todos estos cambios y la salida de Nokia, genera muchas dudas respecto al futuro tecnológico de Qt. Desde nuestro punto de vista Qt sufrirá bastante ya que las empresas participes de la nueva etapa como Canonical, KDE, ICS, Dixia, etc tienen enfoques totalmente distintos en el apartado de movilidad al que tenía Nokia.

V7 es un gran entorno de desarrollo para aplicaciones de gestión empresarial donde el coste, la eficiencia y la colaboración son factores críticos.

Hablemos del presente, hablemos de SaaS

• ¿Para cuando?. Está al caer…
• ¿y estará madura?. No creo, será más bien una versión lite.
• ¿y que hacemos?. Continuar el trabajo de nuestra SaaS.
• ¿Y nuestra web? En proceso… mejorándose para facilitar la entrada, integración y pago.
• ¿LOPD y LSSI para la cuestión fundamental?. Tendremos que ver como está el patio.
• ¿Hay que aprender algo más?. Poco queda, pero es importante seguir avanzado con paso firme.

Hemos aprendido mucho sobre Velneo V7, WordPress, Prestashop, JavaScript, JQuery, Phyton, ShellScript y Amazon EC2/S3. Ahora toca avanzar en lo demás, QML, OAuth, node.js (thanks, @FranVarona), LXC, Qt, Comunicaciones unificadas…

Comunidad

• ¿Que es lo que más cuesta en la adopción?. Hay muchas cosas, pero después de tres años de trabajo con V7, creo que lo más duro es el cambio de filosofía respecto a v6. Hay que aprender a no usar ciertos patrones de diseño de V6 (tenemos que centrarnos en diseños modulares y funcionales), evitar columnas calculadas (son mucho más lentas), evitar duplicidades de código en la medida de lo posible (incrementa el peso y mantenimiento)…
• ¿Habrá negocio para todos en V7?. Si. Surgirán oportunidades en este entorno, pero cuidado, pueden ser contraproducentes. Hay que ser prudentes, centrarse y caminar correctamente alineados.

Con V7 hay que hacer las cosas con otra mentalidad, con otra visión de negocio. Cuando haces el cambio consigues cosas muy interesantes con muy buena salida comercial y empresarial.

Hay que dar tiempo a los desarrolladores, el mercado irá marcando las pautas.

Blog | Tienda

Cuesta de enero

Intentaremos explicar paso a paso como realizar un cliente de twitter básico mediante OAuth y API’s REST/XML.

Conceptos básicos OAuth: Usuarios, OAuth Consumer y OAuth Service Provider

Para poder hablar de OAuth, se necesitan tres partes, un servidor o proveedor de servicios, usuarios y un consumidor:

• OAuth Service Provider o proveedor de servicios OAuth: Sitios o servicios web que contienen información de usuarios cuyo acceso es restringido. Algunos de los más conocidos son Facebook, Twitter o Youtube. Estos proveedores ponen a disposición de los desarrolladores una API que soporta el protocolo de autenticación OAuth.
• Usuarios: Sin los usuarios, no existiría OAuth. Por usuario se entiende cualquier persona que tiene una cuenta de usuario en un Service Provider.
• OAuth Consumer: Cualquier sitio o aplicación web, móvil o de escritorio que solicita permiso a un usuario para acceder a sus datos de acceso restringido que alberga un Service Provider. El usuario puede autorizar o denegar el acceso del consumer a sus datos.

API Key y Callback URL

Cada OAuth Service Provider os proporcionará un API Key (un string de letras y números) para identificar que las peticiones que recibe mediante su API vienen de un OAuth Consumer autorizado, es decir, vuestra aplicación.

A su vez, cada OAuth Service Provider os pedirá que indiquéis un Callback URL, es decir, una dirección URL que apunte a un archivo de vuestra aplicación el cual se encargará de procesar la respuesta de autorización (o desautorización) de acceso a los datos de la cuenta del Usuario en el OAuth Service Provider.

Fujo en OAuth 1.0a

• Obtenemos un Request Token
• Solicitamos la autorización del Usuario (para acceder a los datos de su cuenta) enviándole a una página especial de login del Service Provider.
• Cambiamos el Request Token por un Access Token

Punto de partida

Como punto de partida utilizaremos un ejemplo implementado íntegramente en QML y javascript (https://gitorious.org/qt-qml-demo-playground/qt-qml-demo-playground/trees/master/twitter-oauth)

Este ejemplo contiene dos librerías javascript importantes:

• sha1.js: Una librería que implementa SHA-1
• OAuth.js: Una librería que implementa OAuth 1 (no usar en producción)

Obtenemos un Request Token

Realizamos la solicitud del token (OAuth.qml – línea 70):

Obteniendo el token y la clave secreta (línea 78 y 79).

Solicitamos la autorización del Usuario (para acceder a los datos de su cuenta) enviándole a una página especial de login del Service Provider.

Preparamos la petición de autorización (línea 83).

Realizamos la petición de autorización (línea 88).

Rellenamos los datos de autenticación (línea 94 y 95).

Aceptamos el formulario (Línea 96)

Cambiamos el Request Token por un Access Token

Para ello recogemos el pin (línea 99).

Componemos una nueva solicitud (en este caso para el access_token) pasándole como parámetros el pin, token y secret (línea 100).

Ya estamos autenticados.

Realizamos las llamadas a la API

Ahora que estamos autenticados podemos realizar cualquier llamada a la API de twitter, por ejemplo… a la timeline.

Esperamos que esta introducción os sea de ayuda para hacer vuestro primeros pinitos con OAuth.

¿Te gustaría tener un cliente de Facebook o twitter integrado en tú aplicación empresarial?

Desde hace unos meses estamos trabajando en sendos clientes de twitter y facebook para PaaSOS. Estos dos clientes están implementados íntegramente mediante QML y JavaScript. Llegado el momento serán 100% funcionales en Velneo V7.

Se utilizan las API REST de twitter y facebook. También se utilizan los protocolos de Autenticación OAuth 1a y 2 por lo son un buen punto de partida para el estudio de la implementación mediante javascript de sendos clientes para API’s REST y OAuth .

Blog | Tienda

Servicios web – III

Con la proliferación de los servicios web en Internet, surgió un problema de relevancia, la autenticación. Los servicios disponibles han crecido enormemente, y la mayoría de usuarios utilizan  múltiples aplicaciones de terceros: por ejemplo, un usuario consulta su correo en un sistema de webmail, desde el teléfono o desde su cliente de correo. También es habitual la participación en redes sociales como facebook, linkedin, tuenti o twitter, etc. La mayoría de esas aplicaciones requieren que el usuario se autentique; es decir, que demuestre de algún modo (habitualmente usando un identificador de usuario único y una contraseña asociada) que es quien dice ser.

Al tratarse de aplicaciones independientes entre sí, en principio cada una de ellas utilizaría  su propio sistema de autenticación y de gestión de datos personales, lo cual implica inconvenientes al usuario cada vez más graves a medida que el número de sistemas que utiliza crece.

Surge la necesidad de conocer cuales son las tendencias actuales respecto a la autenticación y autorización en Internet.

Autenticación vs. autorización

Antes de seguir, es necesario hacer una distinción clara entre dos tipos de servicios ofrecidos por las tecnologías que vamos a describir.

• Autenticación: consiste en un sistema para certificar que el usuario es quien dice ser; lo más común es utilizar una combinación de identificador de usuario único y contraseña.
• Autorización: consiste en dar acceso a una serie de recursos a un usuario o sistema (para ello, el usuario o el sistema previamente tendrán que haberse autenticado).

Protocolos y estándares ampliamente adoptados

Una primera solución evidente al problema de la autenticación sería el uso  de algún tipo de certificado personal (basado, por ejemplo, en el estándar X.509) emitido y validado por alguna autoridad central  de confianza. Si bien este tipo de certificados son útiles para gestiones  con determinadas entidades,  no son prácticos en general para el acceso a servicios de Internet. Por este motivo han surgido varios protocolos de autenticación y autorización en Internet.

OpenID

El protocolo abierto OpenID, cuya primera versión fue definida en 2005 para su uso en el sitio web LiveJournal, es un protocolo de autenticación federada, y consiste básicamente en que el usuario selecciona un servidor externo (el “proveedor” de OpenID) que va a ser el que va a validar su identidad en un sistema determinado (el “consumidor” de OpenID).

Problemas de OpenID:

• Complejidad: no se implementa fácilmente.
• Seguridad: es un protocolo muy vulnerable al  phishing.
• Privacidad: los proveedores de OpenID tendrán mucha información del usuario.
• Confianza: ¿quién es realmente el usuario?.
• Usabilidad: puede ser incómodo  y/o complejo  para el usuario.
• Adopción: los proveedores de servicios tienen pocos motivos para aceptarlo como autenticación.
• Disponibilidad: se incrementa la dependencia de servidores.
• Patentes: no es un protocolo “tan” abierto.

OAuth

El protocolo abierto OAuth, a diferencia de OpenID, es un protocolo de autorización; más exactamente, de delegación de acceso; es decir, permite definir cómo un tercero va a acceder a los  recursos propios. Empezó a definirse en 2006 y en 2007 se publicó la primera versión oficial.  El propósito de este protocolo es, pues, que un usuario que tiene determinados recursos en un servidor (el “proveedor” de OAuth) pueda dar acceso a un tercero (el “consumidor”, usualmente un sitio web) a parte o todos esos recursos, sin necesidad de que ese tercero conozca su usuario y contraseña, ya que con esos datos tendría el control total de la cuenta.

Problemas de OAuth:

• Complejidad.
• Orientado a navegadores.
• Seguridad.

OAuth 2.0

OAuth 2.0  pretende ser una versión revisada y simplificada de OAuth. Aventaja a la versión anterior en una mayor simplicidad de implementación, y en una arquitectura más robusta y que da soporte a mayor número de plataformas.

Existe cierta confusión sobre si OAuth es o no un protocolo de autenticación de usuario. Estrictamente hablando  no lo es, ya que no define ningún mecanismo  explícito destinado a autenticar la identidad del usuario. Por tanto, cuando se habla del  “mecanismo de autenticación de OAuth”, en realidad  se están refiriendo al mecanismo de autenticación propio del sitio web proveedor de OAuth, que puede ser cualquiera: autenticación http básica, OpenID, etc.

Nuevos Protocolos y estándares

OpenID OAuth Hybrid Protocol

Como hemos visto, OpenID y OAuth son protocolos con objetivos distintos aunque complementarios: autenticación de usuario (federada) y autorización, respectivamente. El protocolo híbrido OpenID OAuth  combina ambos sistemas, integrándolos en una interfaz única.

Facebook Connect

Debido al enorme incremento de usuarios y, en consecuencia, de datos personales que ha experimentado Facebook en los últimos años, la compañía lanzó en 2008 su propio sistema conocido como Facebook Connect.  Con ese movimiento, Facebook pretendía posicionarse como repositorio central de identidad de los usuarios en Internet. En la actualidad Facebook parece haber  abandonado Facebook Connect para adoptar el protocolo 2.0 de OAuth.

OpenID Connect

El protocolo OpenID Connect es la última propuesta para reactivar OpenID. Su propósito es redefinir y simplificar el protocolo construyéndolo sobre el protocolo OAuth; de ese modo se aprovecha el trabajo desarrollado para OAuth, que parece  estar  extendiéndose rápidamente, dotándolo de una funcionalidad estándar de autenticación que, como hemos visto anteriormente, no posee.

Otros sistemas

Algunos de los grandes proveedores de servicios en Internet han definido, en algún momento, su sistema propio  de autenticación y/o autorización. Sin embargo, la mayoría de ellos están adoptando  estándares  como OpenID y, especialmente, OAuth; es el caso, por ejemplo, de MySpace, Twitter o Yahoo!.

Otro estándar abierto para el intercambio de recursos de identidad es Security Assertion Markup  Language (SAML). Está basado en XML, y su principal propósito es servir de marco para protocolos de autenticación federada. Este protocolo sirve de base para algunos sistemas propietarios de single-sign-on, pero no es utilizado por los grandes proveedores de servicios en Internet.

Resumiendo

Blog | Tienda

Servicios Web – II

Blog | Tienda

Feliz Navidad y próspero 2012