Comments/questions inline...
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@redhat.com>
To: 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@redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________hawkular-dev mailing listhawkular-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev