Skip to main content

[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. or 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.

Back to the top