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

Lukas Krejci lkrejci at redhat.com
Mon Jun 15 07:36:02 EDT 2015 

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 at redhat.com>
> > To: 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

More information about the hawkular-dev mailing list