Hi all, I just wanted to let you know about the breaking change in the upcoming Inventory 0.1.0. Following the suite of metrics, inventory will no longer support the tenantID in the URL and will solely rely on Hawkular accounts to hand it the tenantID to use - i.e. it will be the tenant of the currently logged in user or of the persona passed in using the "Hawkular-Persona" header. Cheers, Lukas _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

From: "John Mazzitelli" <mazz(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Thursday, June 11, 2015 9:26:59 AM Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 I thought it was Hawkular-Tenant, not Hawkular-Persona. I used Hawkular-Tenant header name in my changes to support metrics 0.3.5 The name "Hawkular-Persona" is a new one to me. ----- Original Message ----- > Hi all, > > I just wanted to let you know about the breaking change in the upcoming > Inventory 0.1.0. > > Following the suite of metrics, inventory will no longer support the > tenantID > in the URL and will solely rely on Hawkular accounts to hand it the > tenantID > to use - i.e. it will be the tenant of the currently logged in user or of > the > persona passed in using the "Hawkular-Persona" header. > > Cheers, > > Lukas > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

From: "Lukas Krejci" <lkrejci(a)redhat.com&gt; To: hawkular-dev(a)lists.jboss.org Sent: Friday, June 12, 2015 9:02:52 AM Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 On Thursday, June 11, 2015 13:18:43 Stefan Negrea wrote: > Hello, > > I hope we standardize on Hawkular-Tenant at service level. The concept of > the persona is narrow and accounts specific. While we are mapping now > personas to tenants that could change in the future. > > Also, the concepts of tenant and multi-tenancy are easier to document and > understand by external consumers. If/when the individual services are > decoupled and consumed by other projects or independently, there is no > extra documentation needed to explain the multi-tenant capability. > > I actually hope for quite the opposite ;) I hope we standardize on Hawkular Accounts providing auth and (help with) authz and the rest of the components using that info. Alerts and Inventory already do that. I hope Metrics will join soon. You are right that "Hawkular-Persona" is a header that "suggests" authentication rather than multi-tenancy, but that's exactly how it is used in inventory and alerts - we use accounts primarily for authentication. The fact that tenant = persona is not really that important and in fact if we decide in the future that tenant != persona, we might introduce another header, Hawkular-Tenant most probably, that will override the behavior we currently support by equating the auth and multi-tenancy (which btw. makes a lot of sense, at least for now). Metrics currently does not offer any form of authentication as far as I am aware, so an important part of the multi-tenancy picture is missing from it. IMHO the situation in inventory and alerts is much better now in that regard - we delegate the tenant creation/updates, permission grants, etc. to accounts, let it figure out what the user performing a request is in any way it chooses (basic auth, oauth, optionally override default persona with the Hawkular- Persona header, if deemed necessary) and use that to perform security checks. As a user of the current Hawkular I would find it weird to have to specify my creds/token, potentially a persona overriding header AND a tenant header if, as it is right now, the tenant id and the persona id would always be the same. I know that metrics are special and have to function outside of Hawkular, too, but when inside Hawkular, IMHO, they should blend in and not require special treatment - most of all when applying security. If you figure out a way of blending in Hawkular AND functioning on your own nicely, it'd be nice if the rest of us could reuse that solution. But at least for inventory, there is not direct requirement to run outside of Hawkular. > Thank you, > Stefan > > ----- Original Message ----- > > > From: "John Mazzitelli" <mazz(a)redhat.com&gt; > > To: "Discussions around Hawkular development" > > <hawkular-dev(a)lists.jboss.org&gt; Sent: Thursday, June 11, 2015 9:26:59 AM > > Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming > > Inventory 0.1.0 > > > > I thought it was Hawkular-Tenant, not Hawkular-Persona. > > > > I used Hawkular-Tenant header name in my changes to support metrics 0.3.5 > > > > The name "Hawkular-Persona" is a new one to me. > > > > ----- Original Message ----- > > > > > Hi all, > > > > > > I just wanted to let you know about the breaking change in the upcoming > > > Inventory 0.1.0. > > > > > > Following the suite of metrics, inventory will no longer support the > > > tenantID > > > in the URL and will solely rely on Hawkular accounts to hand it the > > > tenantID > > > to use - i.e. it will be the tenant of the currently logged in user or > > > of > > > the > > > persona passed in using the "Hawkular-Persona" header. > > > > > > Cheers, > > > > > > Lukas > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On Jun 15, 2015, at 7:36 AM, Lukas Krejci <lkrejci(a)redhat.com&gt; wrote: I just hope you implement your filter as soon as possible so that all Hawkular components are authenticated against the same way. But I still think that as a user, I'd be opposed to any solution that would require me to duplicate any information - I will have to provide auth info (creds + optionally persona id). If the components need to provide any other info, given the current security model where persona == tenant, then I think that solution wouldn't be good.

On Friday, June 12, 2015 11:39:15 Stefan Negrea wrote: > Hello Lukas, > > You are conflating two concepts in a bad way. First is multi-tenancy and > second is authentication. > It just happens now the path of least resistance > is to couple the concepts. The requirements for each might change over > time, so coupling them straight in the design will have negative effects. > Not only authentication but authorization also ;) That's because multi- tenancy, IMHO, doesn't make much sense without the other two.. I am not sure if multi-tenancy and authentication can be completely separated. As a user of a multi-tenant system (understood from a SaaS perspective), I would be disappointed if users "from other tenants" could access my data.

So while, technically, we can understand multi-tenancy as solely a means of data separation, the end-user expectations of a multi-tenant system include access control and therefore both authentication and authorization.

> Here is how Metrics approaches this: > 1) 'Hawkular-Tenant' header is the tenant differentiator > 2) 'Hawkular-Tenant' validation and verification is not yet defined > 3) For now use a naive approach that accepts and trusts any incoming values > 4) When Hawkular Accounts has the authentication filter ready , Metrics will > defer decisions to Accounts. All the logic will be contained in a single > filter. Some of the logic will be to map an Accounts concept (the strong > guess is Persona) to 'Hawkular-Tenant'. > 5) Any other service will go through a similar process as in step 4; see > > below ... > Accounts contain a single line of code for authentication - and that is reading the current principal from the session context (and assume that that principal is a keycloak principal). The rest of accounts deals with impersonation and authorization which you don't mention here at all. How do you envisage authorization to happen in metrics?

> The process to integrate Metrics into another project: > 1) Find the authentication mechanism (algorithm, service, database, etc.) > 2) Create a filter to integrate with the authentication source > 3) Validate & verify using the external source and then translate to > 'Hawkular-Tenant' > > My proposal revolves around keeping the individual service architecture and > design clean with regards to multi-tenancy. If you do not see any value in > that for Hawkular Inventory then this discussion does not benefit your > project. > What you are proposing makes authentication and authorization optional, mandating a tenant. What alerts and inventory did was basically the opposite. They mandate auth and authz and make tenant optional/deduced. Users will always need to provide credentials to access the components (at least I hope so), so if there is a way of deducing additional information from that, we should IMHO be doing it. > > Thank you, > Stefan > > ----- Original Message ----- > >> From: "Lukas Krejci" <lkrejci(a)redhat.com <mailto:lkrejci@redhat.com>> >> To: hawkular-ev(a)lists.jboss.org <mailto:hawkular-ev@lists.jboss.org> >> Sent: Friday, June 12, 2015 9:02:52 AM >> Subject: Re: [Hawkular-dev] Tenant no longer in URL in the >> upcoming Inventory 0.1.0> >> On Thursday, June 11, 2015 13:18:43 Stefan Negrea wrote: >>> Hello, >>> >>> I hope we standardize on Hawkular-Tenant at service level. The concept >>> of >>> the persona is narrow and accounts specific. While we are mapping now >>> personas to tenants that could change in the future. >>> >>> Also, the concepts of tenant and multi-tenancy are easier to document >>> and >>> understand by external consumers. If/when the individual services are >>> decoupled and consumed by other projects or independently, there is no >>> extra documentation needed to explain the multi-tenant capability. >> >> I actually hope for quite the opposite ;) I hope we standardize on >> Hawkular >> Accounts providing auth and (help with) authz and the rest of the >> components using that info. Alerts and Inventory already do that. I hope >> Metrics will join soon. >> >> You are right that "Hawkular-Persona" is a header that "suggests" >> authentication rather than multi-tenancy, but that's exactly how it is >> used >> in >> inventory and alerts - we use accounts primarily for authentication. >> >> The fact that tenant = persona is not really that important and in fact if >> we decide in the future that tenant != persona, we might introduce >> another header, Hawkular-Tenant most probably, that will override the >> behavior we currently support by equating the auth and multi-tenancy >> (which btw. makes a lot of sense, at least for now). >> >> Metrics currently does not offer any form of authentication as far as I am >> aware, so an important part of the multi-tenancy picture is missing from >> it. >> >> IMHO the situation in inventory and alerts is much better now in that >> regard - >> we delegate the tenant creation/updates, permission grants, etc. to >> accounts, let it figure out what the user performing a request is in any >> way it chooses (basic auth, oauth, optionally override default persona >> with the Hawkular- Persona header, if deemed necessary) and use that to >> perform security checks. >> >> As a user of the current Hawkular I would find it weird to have to specify >> my creds/token, potentially a persona overriding header AND a tenant >> header if, as it is right now, the tenant id and the persona id would >> always be the same. >> >> I know that metrics are special and have to function outside of Hawkular, >> too, >> but when inside Hawkular, IMHO, they should blend in and not require >> special treatment - most of all when applying security. >> >> If you figure out a way of blending in Hawkular AND functioning on your >> own >> nicely, it'd be nice if the rest of us could reuse that solution. But at >> least >> for inventory, there is not direct requirement to run outside of Hawkular. >> >>> Thank you, >>> Stefan >>> >>> ----- Original Message ----- >>> >>>> From: "John Mazzitelli" <mazz(a)redhat.com&gt; >>>> To: "Discussions around Hawkular development" >>>> <hawkular-dev(a)lists.jboss.org&gt; Sent: Thursday, June 11, 2015 9:26:59 >>>> AM >>>> Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming >>>> Inventory 0.1.0 >>>> >>>> I thought it was Hawkular-Tenant, not Hawkular-Persona. >>>> >>>> I used Hawkular-Tenant header name in my changes to support metrics >>>> 0.3.5 >>>> >>>> The name "Hawkular-Persona" is a new one to me. >>>> >>>> ----- Original Message ----- >>>> >>>>> Hi all, >>>>> >>>>> I just wanted to let you know about the breaking change in the >>>>> upcoming >>>>> Inventory 0.1.0. >>>>> >>>>> Following the suite of metrics, inventory will no longer support the >>>>> tenantID >>>>> in the URL and will solely rely on Hawkular accounts to hand it the >>>>> tenantID >>>>> to use - i.e. it will be the tenant of the currently logged in user >>>>> or >>>>> of >>>>> the >>>>> persona passed in using the "Hawkular-Persona" header. >>>>> >>>>> Cheers, >>>>> >>>>> Lukas >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>

Comments/questions inline... > On Jun 15, 2015, at 7:36 AM, Lukas Krejci <lkrejci(a)redhat.com&gt; wrote: > > I just hope you implement your filter as soon as possible so that all > Hawkular components are authenticated against the same way. > > But I still think that as a user, I'd be opposed to any solution that > would > require me to duplicate any information - I will have to provide auth info > (creds + optionally persona id). If the components need to provide any > other info, given the current security model where persona == tenant, > then I think that solution wouldn't be good. Why and to whom would components be providing auth info? My understanding is that we will eventually have the security filter through which all requests are routed. That filter will handle authentication/authorization so that when a request does reach the component endpoint, we can assume authentication/authorization have already been taken care of.

> On Friday, June 12, 2015 11:39:15 Stefan Negrea wrote: >> Hello Lukas, >> >> You are conflating two concepts in a bad way. First is multi-tenancy and >> second is authentication. >> It just happens now the path of least resistance >> is to couple the concepts. The requirements for each might change over >> time, so coupling them straight in the design will have negative effects. > > Not only authentication but authorization also ;) That's because multi- > tenancy, IMHO, doesn't make much sense without the other two.. > > I am not sure if multi-tenancy and authentication can be completely > separated. As a user of a multi-tenant system (understood from a SaaS > perspective), I would be disappointed if users "from other tenants" could > access my data. Agree about data separation, and I do not think there is anything being suggested that would allow for/support this. > So while, technically, we can understand multi-tenancy as solely a means > of > data separation, the end-user expectations of a multi-tenant system > include > access control and therefore both authentication and authorization. I think this conflate the two, separate concerns. As the user I should not have to know or care about the existence of other tenants. From my perspective there is my tenant and that’s it. There might be other tenants, but that should not be a concern to me as it related to authentication and authorization. For example, in a future version suppose we decide to completely replace our authentication/authorization model with something else. That should not (at least in theory) change multi tenancy.

>> Here is how Metrics approaches this: >> 1) 'Hawkular-Tenant' header is the tenant differentiator >> 2) 'Hawkular-Tenant' validation and verification is not yet defined >> 3) For now use a naive approach that accepts and trusts any incoming >> values >> 4) When Hawkular Accounts has the authentication filter ready , Metrics >> will defer decisions to Accounts. All the logic will be contained in a >> single filter. Some of the logic will be to map an Accounts concept (the >> strong guess is Persona) to 'Hawkular-Tenant'. >> 5) Any other service will go through a similar process as in step 4; see >> > >> below ... > > Accounts contain a single line of code for authentication - and that is > reading the current principal from the session context (and assume that > that principal is a keycloak principal). > > The rest of accounts deals with impersonation and authorization which you > don't mention here at all. How do you envisage authorization to happen in > metrics? Other than configuring/applying the filter, I do not envision metrics, nor any other component for that matter, doing authorization. That is the responsibility of accounts.

>> The process to integrate Metrics into another project: >> 1) Find the authentication mechanism (algorithm, service, database, etc.) >> 2) Create a filter to integrate with the authentication source >> 3) Validate & verify using the external source and then translate to >> 'Hawkular-Tenant' >> >> My proposal revolves around keeping the individual service architecture >> and >> design clean with regards to multi-tenancy. If you do not see any value >> in >> that for Hawkular Inventory then this discussion does not benefit your >> project. > > What you are proposing makes authentication and authorization optional, > mandating a tenant. What alerts and inventory did was basically the > opposite. They mandate auth and authz and make tenant optional/deduced. > > Users will always need to provide credentials to access the components (at > least I hope so), so if there is a way of deducing additional information > from that, we should IMHO be doing it. > >> Thank you, >> Stefan >> >> ----- Original Message ----- >> >>> From: "Lukas Krejci" <lkrejci(a)redhat.com <mailto:lkrejci@redhat.com>> >>> To: hawkular-ev(a)lists.jboss.org <mailto:hawkular-ev@lists.jboss.org> >>> Sent: Friday, June 12, 2015 9:02:52 AM >>> Subject: Re: [Hawkular-dev] Tenant no longer in URL in the >>> upcoming Inventory 0.1.0> >>> >>> On Thursday, June 11, 2015 13:18:43 Stefan Negrea wrote: >>>> Hello, >>>> >>>> I hope we standardize on Hawkular-Tenant at service level. The concept >>>> of >>>> the persona is narrow and accounts specific. While we are mapping now >>>> personas to tenants that could change in the future. >>>> >>>> Also, the concepts of tenant and multi-tenancy are easier to document >>>> and >>>> understand by external consumers. If/when the individual services are >>>> decoupled and consumed by other projects or independently, there is no >>>> extra documentation needed to explain the multi-tenant capability. >>> >>> I actually hope for quite the opposite ;) I hope we standardize on >>> Hawkular >>> Accounts providing auth and (help with) authz and the rest of the >>> components using that info. Alerts and Inventory already do that. I hope >>> Metrics will join soon. >>> >>> You are right that "Hawkular-Persona" is a header that "suggests" >>> authentication rather than multi-tenancy, but that's exactly how it is >>> used >>> in >>> inventory and alerts - we use accounts primarily for authentication. >>> >>> The fact that tenant = persona is not really that important and in fact >>> if >>> we decide in the future that tenant != persona, we might introduce >>> another header, Hawkular-Tenant most probably, that will override the >>> behavior we currently support by equating the auth and multi-tenancy >>> (which btw. makes a lot of sense, at least for now). >>> >>> Metrics currently does not offer any form of authentication as far as I >>> am >>> aware, so an important part of the multi-tenancy picture is missing from >>> it. >>> >>> IMHO the situation in inventory and alerts is much better now in that >>> regard - >>> we delegate the tenant creation/updates, permission grants, etc. to >>> accounts, let it figure out what the user performing a request is in any >>> way it chooses (basic auth, oauth, optionally override default persona >>> with the Hawkular- Persona header, if deemed necessary) and use that to >>> perform security checks. >>> >>> As a user of the current Hawkular I would find it weird to have to >>> specify >>> my creds/token, potentially a persona overriding header AND a tenant >>> header if, as it is right now, the tenant id and the persona id would >>> always be the same. >>> >>> I know that metrics are special and have to function outside of >>> Hawkular, >>> too, >>> but when inside Hawkular, IMHO, they should blend in and not require >>> special treatment - most of all when applying security. >>> >>> If you figure out a way of blending in Hawkular AND functioning on your >>> own >>> nicely, it'd be nice if the rest of us could reuse that solution. But at >>> least >>> for inventory, there is not direct requirement to run outside of >>> Hawkular. >>> >>>> Thank you, >>>> Stefan >>>> >>>> ----- Original Message ----- >>>> >>>>> From: "John Mazzitelli" <mazz(a)redhat.com&gt; >>>>> To: "Discussions around Hawkular development" >>>>> <hawkular-dev(a)lists.jboss.org&gt; Sent: Thursday, June 11, 2015 9:26:59 >>>>> AM >>>>> Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming >>>>> Inventory 0.1.0 >>>>> >>>>> I thought it was Hawkular-Tenant, not Hawkular-Persona. >>>>> >>>>> I used Hawkular-Tenant header name in my changes to support metrics >>>>> 0.3.5 >>>>> >>>>> The name "Hawkular-Persona" is a new one to me. >>>>> >>>>> ----- Original Message ----- >>>>> >>>>>> Hi all, >>>>>> >>>>>> I just wanted to let you know about the breaking change in the >>>>>> upcoming >>>>>> Inventory 0.1.0. >>>>>> >>>>>> Following the suite of metrics, inventory will no longer support the >>>>>> tenantID >>>>>> in the URL and will solely rely on Hawkular accounts to hand it the >>>>>> tenantID >>>>>> to use - i.e. it will be the tenant of the currently logged in user >>>>>> or >>>>>> of >>>>>> the >>>>>> persona passed in using the "Hawkular-Persona" header. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Lukas >>>>>> >>>>>> _______________________________________________ >>>>>> hawkular-dev mailing list >>>>>> hawkular-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hawkular-dev > <https://lists.jboss.org/mailman/listinfo/hawkular-dev>