[Fiware-portals] IPs y nombre de dominio de los portales en el testbed y el lab

[Juanjo Hierro]

Hola,

  Creo que ya le había respondido a esta cuestión a Henar en conversación mantenida con ella, pero por si acaso.

  Yo tendría IdMs distintos para el Testbed y FI-LAB.

  Saludos,

-- Juanjo


-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Coordinator
and Chief Architect

FI-PPP Architecture Board chairman

You can follow FI-WARE at:
  website:  http://www.fi-ware.eu
  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
  twitter:  http://twitter.com/FIware
  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932


On 09/08/13 12:33, Antonio Tapiador del Dujo wrote:
Me temo que es Juanjo Hierro quien tiene que contestar a esta pregunta.

Un saludo.

El 08/08/13 17:56, HENAR MUÑOZ FRUTOS escribió:
Tambien podemos desplegarlo fuera de ningun cloud, directamente con  kvm sin openstack. Pero mi pregunta es, vamos a tener un único idM o dos, uno para el testbed y otro para el OIL?
Henar

De: Antonio Tapiador del Dujo [mailto:atapiador at dit.upm.es]
Enviado el: jueves, 08 de agosto de 2013 17:37
Para: HENAR MUÑOZ FRUTOS
CC: fiware-portals at lists.fi-ware.eu<mailto:fiware-portals at lists.fi-ware.eu>
Asunto: Re: [Fiware-portals] IPs y nombre de dominio de los portales en el testbed y el lab

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<mailto: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


________________________________

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



________________________________

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/20130816/49f1f04c/attachment.html>