Efectivamente Henar, no recordaba que el certificado era común
Para responder a tu pregunta hay que considerar el problema de
dependencias circulares que creo que te comentó Álvaro; si tanto el Idm
como el portal de cloud están instalados en el mismo cloud, digamos el
OIL (lab) y hubiera un problema con el idm, para entrar en el cloud a
arreglarlo haría falta la autenticación del idm, que estaría caído.
Por tanto, hablamos de sacar el idm de la propia infraestructura del
cloud que maneja ese portal y ponerlo en otro cloud.
Estaba la opción de cruzarlos, y que el idm del OIL estuviera alojado en
el testbed y viceversa. Pero creo que aún no se ha tomado esa decisión.
Un saludo.
El 08/08/13 17:19, HENAR MUÑOZ FRUTOS escribió:
>
> Hola
>
> Hacen falta dos instancias, una para los casos de uso (testbed) y otra
> para el OIL (lab). Esa instancia a cual pertenecería? Entiendo que el
> certificado es el mismo no? Ya que es *.lab.fi-ware.eu, pero bueno, el
> lunes está nacho por aquí y podrá responder mejor.
>
> Saludos,
>
> Henar
>
> *De:*Antonio Tapiador del Dujo [mailto:atapiador at dit.upm.es]
> *Enviado el:* jueves, 08 de agosto de 2013 15:33
> *Para:* fiware-portals at lists.fi-ware.eu; HENAR MUÑOZ FRUTOS
> *Asunto:* Re: [Fiware-portals] IPs y nombre de dominio de los portales
> en el testbed y el lab
>
> Hola Henar,
>
> por parte del idm, el dominio actual es idm.lab.fi-ware.eu ->
> 130.206.80.69
>
> El dominio final debería ser account.lab.fi-ware.eu, pero necesitamos
> el certificado https antes de poder hacer el cambio de dominio.
>
> Un saludo.
>
> El 07/08/13 10:58, HENAR MUÑOZ FRUTOS escribió:
>
> Buenos días
>
> Me podéis pasar las IPs y los nombre de dominio de los portales, tanto
> en la parte del testbed como del lab (para OIL y campus party)?.
> Además comentarme si necesitáis algún nombre de dominio nuevo y me
> encargué de meterlo en el DNS.
>
> Muchas gracias,
>
> Saludos,
>
> Henar
>
> *De:*fiware-portals-bounces at lists.fi-ware.eu
> <mailto:fiware-portals-bounces at lists.fi-ware.eu>
> [mailto:fiware-portals-bounces at lists.fi-ware.eu] *En nombre de
> *Francisco de la Vega
> *Enviado el:* miércoles, 07 de agosto de 2013 9:14
> *Para:* Antonio Tapiador del Dujo
> *CC:* fiware-portals at lists.fi-ware.eu
> <mailto:fiware-portals at lists.fi-ware.eu>
> *Asunto:* Re: [Fiware-portals] API de notificaciones
>
> Hola,
>
> ¿Cual es el endpoint donde tienen que llegar las notificaciones de
> compra al idM?
>
> Saludos,
>
> Francisco
>
> El 6 de agosto de 2013 17:17, Antonio Tapiador del Dujo
> <atapiador at dit.upm.es <mailto:atapiador at dit.upm.es>> escribió:
>
> Hecho!
>
> El 06/08/13 16:56, Francisco de la Vega escribió:
>
> Hola,
>
> Para el desarrollo estoy utilizando una applicación de testing con
> client_id 16 y necesitaría que pudiera acceder a estas APIs.
>
> Saludos,
>
> Francisco
>
> El 6 de agosto de 2013 16:04, Antonio Tapiador del Dujo
> <atapiador at dit.upm.es <mailto:atapiador at dit.upm.es>> escribió:
>
> Hola Francisco,
>
> ya tienes el API lista en producción. Respecto al token, debería
> valer cualquier formato descrito en el RFC 6750
>
> Solo la aplicación con id 18 debería tener permiso para atacar
> este punto del API. Si tienes otras aplicaciones o pruebas, dime y
> las registro. Cualquier duda o error, no dudes en consultarme
>
> Un saludo.
>
>
> El 05/08/13 18:16, Francisco de la Vega escribió:
>
> Hola,
>
> Las notificaciones quedarían como:
>
> {
> "offering": {
> "organization": "owner_organization",
> "name": "offering_name",
> "version": "offering_version"
> },
> "reference": "referencia_de_compra",
> "customer": "actor_id",
>
> "applications": [{"id": 16,
> "name": "app"},
> {"id":20,
> "name":"app2"}]
>
> }
>
> El campo customer contendria el actor_id tanto de un usuario
> como de una organización.
>
> Por otra parte ¿como quieres el token?, ahora mismo lo paso en
> la cabecera Authentication: Bearer .token.
>
> Saludos,
>
> Francisco
>
> El 5 de agosto de 2013 17:46, Antonio Tapiador del Dujo
> <atapiador at dit.upm.es <mailto:atapiador at dit.upm.es>> escribió:
>
> Hola Fancisco, también tienes lista el API de aplicaciones:
>
> https://github.com/ging/fi-ware-idm/wiki/API#applications
>
> El endpoint de compras en el IdM puede ser /purchases, ¿cómo
> queda el JSON al final?
>
> Un saludo.
>
>
> El 02/08/13 14:34, Antonio Tapiador del Dujo escribió:
>
> Estupendo, ya lo tienes tanto en el wiki como desplegado en
> producción
>
> https://github.com/ging/fi-ware-idm/wiki/Using-the-deployed-instance
>
> Por cierto, he aprovechado para cambiar el parámetro
> organization.name <http://organization.name> a
> organization.displayName siguiendo el esquema de grupos de
> SCIM que se ha acordado como API en el paquete de seguridad.
> Aún tengo la tarea pendiente de revisarlo en profundidad, por
> lo que es posible que haya algún que otro pequeño cambio. Os
> aviso.
>
> Un saludo.
>
> El 02/08/13 13:15, Francisco de la Vega escribió:
>
> OK, entonces creo que estaría bien pasar el actor_id como
> customer, de hecho me vendría bien para gestionar otras cosas
> de los usuarios y organizaciones en el Store.
>
> El 2 de agosto de 2013 13:10, Antonio Tapiador del Dujo
> <atapiador at dit.upm.es <mailto:atapiador at dit.upm.es>> escribió:
>
> Como veas, cambiar el API me supone escribir una línea más de
> código, así que no es mucho problema. Lo que quede mejor.
>
>
> El 02/08/13 13:09, Francisco de la Vega escribió:
>
> Creo que lo mas sencillo sería incluir un tipo
> (organización o usuario) e incluir su id. Lo del actor_id
> estaría bien pero te forzaría a cambiar la API para
> incluir ese valor en la respuesta.
>
> El 2 de agosto de 2013 13:03, Antonio Tapiador del Dujo
> <atapiador at dit.upm.es <mailto:atapiador at dit.upm.es>> escribió:
>
> En el IdM el nombre de la organización no es único.
> Existen nicknames tanto para organizaciones como usuarios
> que son únicos pero no inmutables, es decir, tanto
> usuarios como organizaciones los pueden cambiar, aunque
> deben poner uno que no esté cogido. Lo que es único e
> inmutable son los ids, tanto por usuario como organización.
>
> Los ids se pueden repetir entre distintos modelos. Es
> decir, hay organizacion 1 y usuario 1. Existe otro id en
> el idm, el id de actor, que sí es único para usuarios,
> organizaciones y aplicaciones. Es decir, si existe usuario
> con actor_id == 1 no puede existir organizacion con
> actor_id == 1.
>
> Usando nicknames ahora mismo podría existir condiciones de
> carrera, es decir, un usuario carga la página de una
> organización en la store, la organización cambia su
> nickname y posteriormente se realiza la compra.
>
> Yo me quedaría más tranquilo si incluís un id por cliente,
> tal como 'organization-1' usando los ids de organizacion,
> o directamente el id de actor. ¿Qué te parece?
>
>
> El 02/08/13 12:52, Francisco de la Vega escribió:
>
> Creo que en el caso del idM lo mejor es tener una URL
> única a la que mandar las peticiones, por otra parte
> el customer ahora mismo contiene el nickname del
> usuario o el nombre de la organización dependiendo de
> como se haga la compra (En el Store el nombre de una
> organización es único), si el nombre de las
> organizaciones no es único en el idM podría incluir un
> campo más con el identificador de la organización
> (estoy suponiendo que se puede identificar un usuario
> por su nickname).
>
> Saludos
>
> El 2 de agosto de 2013 12:40, Antonio Tapiador del
> Dujo <atapiador at dit.upm.es
> <mailto:atapiador at dit.upm.es>> escribió:
>
> Estupendo Francisco, un par de dudas:
>
> * ¿Manejamos la misma URL en el IdM para cada oferta,
> o se necesita registrar una nueva URL por oferta?
> * ¿customer es el nombre de la organización o usuario
> cliente? Este nombre puede no ser único o cambiar ¿Se
> podría pasar el id y/o tipo?
>
> El 02/08/13 10:41, Francisco de la Vega escribió:
>
> Hola,
>
> Con respecto a la API de notificaciones, el Store
> manda una petición POST a la URL registrada al
> crear la oferta con un content type
> application/json y con el cuerpo:
>
> {
> "offering": {
> "organization": "owner_organization",
> "name": "offering_name",
> "version": "offering_version"
> },
> "reference": "referencia_de_compra",
> "customer": "usuario_u_organización_cliente"
> }
>
> Entiendo que para la integración con el idM lo
> único que haría falta seria incluir un un campo
> conteniendo las aplicaciones compradas, algo como:
>
> POST
> Content-Type: application/json
>
> {
> "offering": {
> "organization": "owner_organization",
> "name": "offering_name",
> "version": "offering_version"
> },
> "reference": "referencia_de_compra",
> "customer": "usuario_u_organización_cliente",
> "applications": [{"id": 16,
> "name": "app"},
> {"id":20,
> "name":"app2"}]
> }
>
> Saludos,
> Francisco
>
> _______________________________________________
>
> Fiware-portals mailing list
>
> Fiware-portals at lists.fi-ware.eu <mailto:Fiware-portals at lists.fi-ware.eu>
>
> https://lists.fi-ware.eu/listinfo/fiware-portals
>
>
> _______________________________________________
> Fiware-portals mailing list
> Fiware-portals at lists.fi-ware.eu
> <mailto:Fiware-portals at lists.fi-ware.eu>
> https://lists.fi-ware.eu/listinfo/fiware-portals
>
> ------------------------------------------------------------------------
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede
> consultar nuestra política de envío y recepción de correo electrónico
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send
> and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>
>
> _______________________________________________
> Fiware-portals mailing list
> Fiware-portals at lists.fi-ware.eu <mailto:Fiware-portals at lists.fi-ware.eu>
> https://lists.fi-ware.eu/listinfo/fiware-portals
>
>
> ------------------------------------------------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede
> consultar nuestra política de envío y recepción de correo electrónico
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send
> and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-portals/attachments/20130808/a1222fd7/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy