[Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0

Lukas Krejci lkrejci at redhat.com
Tue Jun 16 13:48:35 EDT 2015


On Monday, June 15, 2015 10:45:25 John Sanda wrote:
> Comments/questions inline...
> 
> > On Jun 15, 2015, at 7:36 AM, Lukas Krejci <lkrejci at redhat.com> 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.

Users would be supplying auth info. Authorization is impossible to do 
generically imho and has to be done by components - only the components know 
their security model. Accounts can provide the tools to facilitate the 
authorization but it must be the components that use those tools to apply the 
authorization in a component-specific way.

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

That is precisely what I was trying to imply - as a user I should not care 
what a tenant is. I should just provide my creds + optionally impersonation 
info (if a user wants to act as an org for example).

"Hawkular-Tenant" header goes against that if it would be the user that would 
be supplying that info.

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

-1. Metrics have completely different authz requirements from alerts which are 
completely different from inventory's authz reqs. It is the components or a 
dedicated wrapper thereof that need to do the authz. Accounts can help with 
that but the logic will be component specific.

> >> 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 at redhat.com <mailto:lkrejci at redhat.com>>
> >>> To: hawkular-ev at lists.jboss.org <mailto:hawkular-ev at 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 at redhat.com>
> >>>>> To: "Discussions around Hawkular development"
> >>>>> <hawkular-dev at lists.jboss.org> 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 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
> >> 
> >> _______________________________________________
> >> 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 <mailto:hawkular-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > <https://lists.jboss.org/mailman/listinfo/hawkular-dev>




More information about the hawkular-dev mailing list