Header Ads Widget

Ticker

6/recent/ticker-posts

Desde el inicio hasta RFC: la historia de SCIM


Ocho años es mucho tiempo en cualquier negocio, pero quizás no sea más cierto que en el espacio tecnológico. Consiéntenos por un momento y pensemos en 2010 ...

Vimos a Jesse Eisenberg vinculado para siempre con Mark Zuckerberg por The Social Network . Obamacare hizo su controvertido debut. El iPhone 4 de vanguardia también apareció en las tiendas por primera vez. 2010 también marcó el nacimiento de SCIM .

Kelly Grizzle de SailPoint se unió a nosotros en nuestra Austin API Summit en 2018 para contarnos cómo SCIM pasó de una idea vaga a algo con tres RFC (casos de uso, esquema y API) que se han adoptado miles de veces. Pero también hizo mucho más que eso.

Al explicar la evolución de SCIM, Grizzle proporciona un plan para cualquier desarrollador que lleve una API al mercado en el espacio estándar de código abierto / Internet, pero su historia (con los consejos prácticos, las lecciones de diseño y las aplicaciones inesperadas que sacaremos de ella) es uno que cualquier persona que desee crear una API resistente y duradera puede beneficiarse de la lectura.

Vea a Kelly Grizzle explicar la historia de SCIM en la Cumbre API de Austin 2018:

Diapositivas

SCIM-ing la superficie

Empecemos con lo básico. Para aquellos de ustedes que no lo saben, SCIM son las siglas de System for Cross-Domain Identity Management, pero originalmente se conocía como Simple Cloud Identity Management.

Es una API REST para la gestión de identidades que se creó con el siguiente objetivo en mente: "Hacer que sea rápido, económico y fácil mover usuarios dentro, fuera y alrededor de la nube".

En 2010, OAuth estaba construyendo una buena participación de mercado y una autorización estandarizada, mientras que SAML estaba creando estándares para el inicio de sesión único (SSO). "Pero había un agujero en este rompecabezas", dice Grizzle. "¿Qué pasa con la gestión de identidad?"

En el verano de 2010, en Cloud Identity Summit, un grupo de lo que Grizzle llama cariñosamente "geeks de administración de identidades" comenzó a dar vueltas al siguiente problema: debido a que no había estándares para la administración de identidades, cada producto tenía su propia API de administración de identidades única, que les dificultaba la comunicación a todos.

Lea también: SCIM: Creación de la capa de identidad para Internet

De Pet Project a API

La autoproclamada "nerd de la identidad" Kelly Grizzle traza el recorrido de SCIM, desde el proyecto de colaboración hasta la API estándar de Internet bien adoptada.

Sobre la cuestión de cómo empezar, Grizzle ofrece consejos muy parecidos a los de la mayoría de las prendas deportivas de Nike: ¡ hazlo!

Explica cómo, en el caso de SCIM, el objetivo principal era moverse rápido y generar impulso. La mayoría de las veces es una decisión inteligente porque las brechas en el mercado, particularmente cuando están involucradas tecnologías nuevas y emergentes, no permanecen brechas por mucho tiempo. Por supuesto, los proyectos más exigentes requieren explorar si existe o no demanda para el producto.

SCIM 1.0 y 1.1 se desarrollaron bajo la Open Web Foundation, que ofrece (en palabras de Grizzle) "una forma rápida y flexible de compartir la propiedad intelectual". Significó que personas de diferentes empresas, áreas del mundo, etc. pudieron reunirse y trabajar en común con el lado legal de las cosas que ya se habían resuelto.

Solo más tarde el grupo se trasladó al Grupo de trabajo de ingeniería de Internet 9 (IETF) para hacer un RFC más formal. Obviamente, el enfoque de “comenzar informalmente, formalizar después” no siempre será factible para quienes trabajan en nombre de las organizaciones, pero vale la pena tenerlo en cuenta para las API que se sienten más como proyectos paralelos que como empresas comerciales masivas.

Relacionado: Gestión de usuarios estandarizada con SCIM

Utilice las mejores prácticas existentes

Grizzle dice de SCIM que "no queríamos reinventar la rueda necesariamente, solo queríamos ... encontrar las mejores prácticas y unirlas todas". En el espacio de API, como es el caso en la mayoría de las otras áreas de negocios, es aconsejable estar al tanto de las mejores prácticas actuales.

Eso no significa que no pueda desviarse de las mejores prácticas donde lo considere oportuno, pero al menos debería saber cuáles son. Para Grizzle y SCIM, en la práctica, eso significó examinar muchas API de administración de identidad existentes:

  • Contactos portátiles usados ​​como base para el esquema
  • Consulta y paginación basada en OpenSearch
  • Determine los casos de uso mediante la recopilación de otras API

En otras palabras, una vez que supieron que había una brecha en el mercado para su producto, utilizaron datos y metodologías que ya estaban disponibles para construir algo que sabían (o quizás esperaban) que pudiera llenar esa brecha.

Extensibilidad y flexibilidad

Grizzle habla extensamente sobre la importancia de la flexibilidad al crear un servicio API: “Si alguien te envía una respuesta que parece un poco fuera de lugar, trata de lidiar con ella. No se rompa de inmediato ... Sea un poco más firme en lo que permite dentro de la puerta de entrada ".

En el caso de SCIM, esto significó un esquema central RFC que define Usuario y Grupo, así como un lenguaje que define otros esquemas. Esto permite, por ejemplo, a los usuarios:

  • Ampliar los tipos de recursos existentes (por ejemplo, un usuario empresarial)
  • Agregar nuevos tipos de recursos (por ejemplo, dispositivo de IoT)

“Si no tuviéramos esto”, dice Grizzle, “la gente tomaría SCIM y lo tiraría por la ventana inmediatamente. Si no es lo suficientemente flexible, no cumplirá con ningún caso de uso ". También cita la ley de (Jon) Postel para la implementación de TCP y la modifica para construir una API exitosa: "Sea conservador en lo que hace, sea liberal en lo que acepta de los demás".

Puede parecer obvio, pero no se puede exagerar lo valiosas que son la flexibilidad y la extensibilidad para la longevidad de una API. Muchos en la escena tecnológica ven a las API como ladrillos de Lego , y tratar de forzar una pieza de K'Nex o un Super Blok en la mezcla puede ser seriamente desalentador.

Consulte también: 9 preguntas para la auditoría de seguridad de API de nivel superior

Espere desafíos y sorpresas

Grizzle describe algunos de los desafíos que enfrentó el equipo de SCIM al escalar y vale la pena mencionarlos aquí porque, aunque es posible que no sean exactamente lo que el desarrollador de API promedio enfrentará al crear un nuevo producto, ciertamente hay algunos paralelos:

  • El camino hacia el IETF es lento , pero valió la pena el esfuerzo de SCIM porque aumentó la exposición y permitió al equipo obtener diferentes perspectivas sobre su trabajo.
  • Fueron demasiado ambiciosos con su operación PATCH, y como resultado lo diseñaron dos veces, y Grizzle admite que hay cosas que desearía que se hubieran hecho de manera diferente.
  • Adopción lenta : se necesita tiempo para alcanzar la masa crítica y necesita evangelistas u obtener la aceptación temprana de los actores clave para lograr un crecimiento exponencial

Desafortunadamente, no existen soluciones fáciles para la mayoría de los problemas anteriores. Grizzle bromea diciendo que “es bueno tener grandes amigos ahí fuera”, pero eso no hace que sea más fácil lograr que empresas como Salesforce o Google se interesen en lo que estás trabajando a menos que tengas una relación con ellos.

Además, debe estar preparado para que las personas usen su producto de formas muy diferentes a las que espera. Grizzle menciona que SCIM se "creó teniendo en cuenta los casos de uso de la nube, pero muchas de las primeras implementaciones del mundo real se realizaron en grandes empresas detrás de firewalls".

Pensamientos finales

La historia de SCIM difiere de la mayoría de nuestros estudios de casos, que generalmente cuentan con API públicas, de socios o privadas / internas, porque es una API estándar de Internet . La perspectiva puede ser un poco diferente, pero es interesante notar que todos esos procesos tienen mucho en común.

Si bien los desafíos que se enfrentan en el camino no serán exactamente los mismos para todos los desarrolladores de API, SCIM representa una evolución impresionante desde un proyecto paralelo ideado por un grupo de "geeks de administración de identidades" a una fuerza dominante en el espacio utilizado por Cisco. Salesforce, Google y otros.

La creación de una API, ya sea una labor de amor o parte de un proyecto en el trabajo (¡o ambas cosas!), Siempre es una tarea abrumadora. Es reconfortante recordar que un proyecto de colaboración ideado durante el tiempo de inactividad en una conferencia puede terminar convirtiéndose en un estándar abierto en su espacio.

Desde el inicio hasta RFC: la historia de SCIM de las API nórdicas

Publicar un comentario

0 Comentarios