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

Tue May 12 09:17:34 EDT 2015

----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Tuesday, May 12, 2015 8:08:36 AM
> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> 
> You mean use _hawkularTenant_ instead of the _tenant_ query param? That
> makes less sense to me.

I would use an identical query parameter so consumers that do not want/have the option to use headers can just append an identical query parameter. The hyphen is not reserved, therefore it can be used as part of the query parameter name or value without encoding. Correct me if I am wrong about the hyphen.

http://tools.ietf.org/html/rfc3986#section-2.3

> 
> Le 12/05/2015 15:05, Stefan Negrea a écrit :
> >
> > Good proposal, just make sure it is carried over to the query parameter
> > alternative too.
> >
> >
> > ----- Original Message -----
> >> From: "Thomas Segismont" <tsegismo at redhat.com>
> >> To: hawkular-dev at lists.jboss.org
> >> Sent: Tuesday, May 12, 2015 7:36:56 AM
> >> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> >>
> >>  From IETF:
> >> ===
> >> 3.  Recommendations for Creators of New Parameters
> >>
> >>      Creators of new parameters to be used in the context of application
> >>      protocols:
> >>
> >>      1.  SHOULD assume that all parameters they create might become
> >>          standardized, public, commonly deployed, or usable across
> >>          multiple implementations.
> >>
> >>      2.  SHOULD employ meaningful parameter names that they have reason to
> >>          believe are currently unused.
> >>
> >>      3.  SHOULD NOT prefix their parameter names with "X-" or similar
> >>          constructs.
> >>
> >>      Note: If the relevant parameter name space has conventions about
> >>      associating parameter names with those who create them, a parameter
> >>      name could incorporate the organization's name or primary domain name
> >>      (see Appendix B for examples).
> >> ===
> >> http://tools.ietf.org/html/rfc6648#section-3
> >>
> >> So the header should be something like "Hawkular-Tenant". And shared
> >> across the individual components.
> >>
> >> I'll file a Metrics JIRA unless someone has a strong objection or better
> >> name.
> >>
> >> Le 28/04/2015 17:44, Stefan Negrea a écrit :
> >>> 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
> >
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 