[Hawkular-dev] Tenant Id - Not Part of URL

Wed Apr 29 12:46:33 EDT 2015

Well, for inventory, we're considering dropping the context of a tenant 
altogether.

Accounts don't work with a tenant in a usual meaning of that word very well - 
in accounts there is nothing like an isolated "island" that cannot be accessed 
by anyone outside of that island.

Instead, accounts work with a hierarchy of organizations, of which users can 
be members of (and have different roles in) and impersonate them.

In inventory, we're using tenants rather loosely - while they form a root of 
the path to any other entity in inventory, it is not disallowed to link 
entities from different tenants.

A single tenant as a root of the hierarchy doesn't correspond well to the 
hierarchical nature of accounts organizations. So instead, to offer similar, 
if disconnected, approach to structuring things, we are thinking about 
replacing a single tenant with a hierarchy of "partitions" or "locations" (the 
nomenclature is not settled as isn't the concept itself ;) ). The thinking 
behind it is that while orgs model the departmental and security structure of 
a company, the partitions/locations would/could model the physical location of 
machines in the company's infrastructure (/geo5/datacenterA/...) or they could 
model a logical structure of the machines (/middleware/client5/...), or they 
even could mirror the security structure of orgs.

In any case, given the fact that either tenant or any of its successors are 
iherent part of a an ID of any entity (entities in inventory are identified by 
their path, not by a unique ID), I think we will have to keep them in the 
URI's, too, as it would not make sense to address things like:

http://.../EAP-5?tenantId=x

because 

http://.../EAP-5?tenantId=y

is most probably an utterly different thing that is completely unrelated to 
the first one.

On Wednesday, April 29, 2015 12:28:50 John Sanda wrote:
> Will the REST APIs for other hawkular services take a similar approach? This
> seems like an area where we want to be consistent across APIs.
> > On Apr 28, 2015, at 3:58 PM, Lukas Krejci <lkrejci at redhat.com> wrote:
> > 
> > How do metrics' tenants fit into the hawkular accounts and its persona
> > concept?
> > 
> > ----- Original Message -----
> > 
> >> From: "Stefan Negrea" <snegrea at redhat.com>
> >> To: "Discussions" <hawkular-dev at lists.jboss.org>
> >> Sent: Tuesday, 28 April, 2015 5:44:56 PM
> >> Subject: [Hawkular-dev] Tenant Id - Not Part of URL
> >> 
> >> Hello Everybody,
> >> 
> >> I've been working on a PR for the upcoming Hawkular Metrics release that
> >> will remove the tenant id from the end-point URLs. The tenant id will be
> >> moved to either a header parameter or a query parameter. The query
> >> parameter is in place for cases (such as curl) where setting a header is
> >> not possible, difficult, or inconvenient.
> >> 
> >> Here is an example of the change:
> >> 
> >> Existing URL:
> >> /{tenantId}/gauge/{metricId}/data
> >> 
> >> New URL:
> >> /gauge/{metricId}/data
> >> 
> >> Tenant id set via:
> >> 1) header - tenantId
> >> 2) query parameter - tenantId
> >> 
> >> 
> >> There are two exceptions to this rule, /tenants and
> >> /db/{tenantid}/series.
> >> The /tenants end-point will be changed into something different in the
> >> upcoming releases since it is mostly a management type API that does not
> >> belong in the same place with the regular metrics endpoint. And
> >> /db/{tenantid}/series end-point is needed in this exact format for
> >> compatibility with Influxdb compatible services.
> >> 
> >> 
> >> Now, to the merits of this change. The tenant id is volatile, can change
> >> any time, and changes to it should be expected; but the rest of the URL
> >> is fixed. The second issue is that the tenant id is a security concern.
> >> So we were limited in design choices since a security concern was
> >> leaking as part of the URL.
> >> 
> >> So removing the tenant id from the URL will give us permanent &
> >> consistent
> >> addresses for resources (metrics and metric data points). And we will
> >> gain a lot of flexibility on the security side. In the future, users
> >> could authenticate with a user/pass combo and the backend would
> >> transform that into a tenant id to be used on the request. If the same
> >> user later decides to use a tenant id to pass along the request, the URL
> >> of the resources would not change. Another expectation is that tenant id
> >> is not sufficient, it is typically a combo of id + secret; so we would
> >> have resorted to a header or query param for the second piece of
> >> information (the secret).
> >> 
> >> This change will give us the flexibility to adjust the security model
> >> (the
> >> meaning of tenant ids and ways to validate them) without compromising the
> >> URL structure. This will help Hawkular Metrics as it gets integrated into
> >> more and more projects and products.
> >> 
> >> Here are the links to the JIRA and the PR for this change:
> >> https://github.com/hawkular/hawkular-metrics/pull/202
> >> https://issues.jboss.org/browse/HWKMETRICS-68
> >> 
> >> 
> >> 
> >> Thank you,
> >> Stefan Negrea
> >> 
> >> Software Engineer
> >> 
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev