[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Agenda for face-to-face meeting
|
On 01/04/16 09:51, Hudalla Kai (INST/ESY) wrote:
-----Ursprüngliche Nachricht-----
Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Gordon Sim
Gesendet: Donnerstag, 31. März 2016 19:29
An: hono-dev@xxxxxxxxxxx
Betreff: Re: [hono-dev] Agenda for face-to-face meeting
[...]
* In uploading telemetry data, the tenant-id is optional. If not provided how is that
determined? Is a default assumed? Or is there some lookup of the tenant to which
a device belongs? If the tenant *is* specified is there any verification that it
matches the owner of the device?
[KH] So far we have discussed that we want to imply a "Default" tenant if the tenant-id is omitted. This would make it easier for customers to use Hono in a single tenant environment. A lookup of the tenant-id is also possible, however (with the additional latency penalty involved, of course). Regarding verification of tenant-id: my take is that we will want to authenticate Protocol Adapters as kind of a _trusted_ component to which we delegate the authentication of the devices and the establishment of the tenant they belong to.
I was assuming you would authorise access to a given tenant's namespace
by the authenticated prinicipal of each connection. That way if some
tenant needs to use their own custom protocol adapter, you can limit
access to avoid any accidental impact on other tenants.
You can still allow another protocol adapter to serve multiple tenants,
it would just authenticate as a principal with sufficient privileges. A
separate question then is whether messages for different tenants can be
sent on the same connection or whether each connection is associated
with a single tenant.
When you say 'establishment of the tenant they belong to', do you mean
that the tenant would be determined from the devices identity? That
would require global uniqueness of the device identifiers, even across
different tenants.
* Depending on answers to the above, might the tenant be identified via a virtual
hostname on the connection open?
[KH] This is just another means of conveying the information, isn't it? So, instead of supplying it at the message level, we convey it in the node address used in the link establishment, right? This could also work, I guess but doesn't solve the problem of trustworthiness of the information provided, does it?
Yes, it is just another way to identify the tenant. I think there are
three levels at which the tenant can be indicated:
(1) connection-level, e.g. a virtual hostname or a connection property
(2) link-level, e.g. part of the address for sender/receiver
(3) message-level, i.e. a custom message property or annotation
These are not mutually exclusive of course (as long as it is
consistent). I guess the most important question is how the tenant
information is used and by which component.
If access to a tenants data is authorised within hono, then doing it per
sender or per connection is probably better than per message.
I quite like using the virtual hostname because it is less intrusive for
users. They don't really need to care too much about the notion of
tenant id, they just have different hostnames e.g. project-foo.acme.org
or my-iot-app.somecorp.com. Having the tenant-id in the namespace
somehow makes them more aware of the multi-tenancy. This of course is
largely personal preference and may be driven by a mistaken view of what
tenancy means to Hono.
