8:14 a.m.
Bringing this discussion to the list. Summary so far:
===
If all those requirements got dropped, specially "multiple
organizations" and "multi tenancy", then there's really no point in
having Accounts. Without the UI/self-registration/SSO, I doubt we need
to depend on Keycloak. I added SSO to this list because if there will be
no user interaction on Hawkular, there's no "single sign on" required
there.
It's still not clear to me, though, if we need to care about
authorization. Are we getting calls only from "trusted" clients? Also,
should we use the same user base as MiQ, or should we have a "system
account" only? Having a system account might make more sense here, and
we won't need to integrate with their user database.
With this system account, we would act like a database: any user with
valid credentials would be allowed to read/write data. We would trust
the client if the client said "store this data for this tenant".
Instead of tokens, we could have just system accounts. Revoking a token
would mean just removing this system account.
===
On 15 Apr 2016, at 14:38, John Mazzitelli wrote:
What about agents/feeds? They aren't talking to CFME ; they are
talking directly to the Hawkular Server (or Hawkular-Metrics if in
METRICS-ONLY mode, such as in Open Shift). Is there not going to be
any Basic Auth headers anymore? If there will still need to be
authentication, then it must be the JAAS credentials and not the
Accounts tokens, I suppose.
If we have system accounts, then agents would use a system account, like
they would use a token. Admins are free to create one system account per
agent (key/secret), or use one shared account to all agents
(jdoe/password). For all "we" (Hawkular backend) care, it's all done by
JAAS. In fact, if all goes well, there will be no need to change
anything for the agents.
And I'm considering that the auth is done by Basic auth. If we *need* to
have other authentication mechanisms, we need to deviate from JAAS.
On 15.04.2016 14:43, Heiko W.Rupp wrote:
Yes, that *may* require a change. Or not if we e.g. have
- accounts-keycloak
- accounts-jaas
where the latter does the mapping as a jaas provider/plugin.
But yes we need to secure the agent/server comm. And we
need to apply SSL for the product (isn't that part of http/2 anyway).
So far, I don't see the need in having Keycloak, or Accounts. Securing
the agent/server communication is not relevant to the discussion, as
it's independent from the authentication mechanism being used.
- Juca.
9:57 a.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
On 15.04.2016 15:14, Juraci Paixão Kröhling wrote:
On 15.04.2016 14:43, Heiko W.Rupp wrote:
> Yes, that *may* require a change. Or not if we e.g. have
> - accounts-keycloak
> - accounts-jaas
> where the latter does the mapping as a jaas provider/plugin.
I'm still not convinced why we would need two modules. If we assume that
Hawkular is similar to a database, in the sense that end users have no
access to it, then there would be no need for any advanced feature from
Keycloak. Plain JAAS would suffice.
- Juca.
10:14 a.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
On 18.04.2016 16:57, Juraci Paixão Kröhling wrote:
On 15.04.2016 15:14, Juraci Paixão Kröhling wrote:
> On 15.04.2016 14:43, Heiko W.Rupp wrote:
>> Yes, that *may* require a change. Or not if we e.g. have
>> - accounts-keycloak
>> - accounts-jaas
>> where the latter does the mapping as a jaas provider/plugin.
I'm still not convinced why we would need two modules. If we assume that
Hawkular is similar to a database, in the sense that end users have no
access to it, then there would be no need for any advanced feature from
Keycloak. Plain JAAS would suffice.
Sent without finishing :)
Another aspect that comes with the removal of the dependency on Keycloak
is surrounding tenancy. We don't have the same requirements as before,
and in the case described above where Hawkular could be seen as a
"database", the tenancy would/should be managed on the user-facing
application.
This means that we'd have a breaking change for components like
Inventory and Metrics, where the tenant is currently the same as the
persona, which in turn is derived from the logged in user (or
organization selected on the account switcher). Not having a tenancy
model anymore means that all users are of the same tenant, so,
components that care about tenancy should be changed.
Note that there are two ways of interpreting "tenancy" here: the first
is about how data is stored, and the second is how data is accessed.
Previously, a tenant would write and read only its own data. Now, tenant
is just another piece of the data, so, components would not actively
check if the data belongs to the current user. We trust that the
user-facing application is performing these checks.
- Juca.
11:43 a.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
2016-04-18 17:14 GMT+02:00 Juraci Paixão Kröhling <jpkroehling(a)redhat.com>:
On 18.04.2016 16:57, Juraci Paixão Kröhling wrote:
> On 15.04.2016 15:14, Juraci Paixão Kröhling wrote:
>> On 15.04.2016 14:43, Heiko W.Rupp wrote:
>>> Yes, that *may* require a change. Or not if we e.g. have
>>> - accounts-keycloak
>>> - accounts-jaas
>>> where the latter does the mapping as a jaas provider/plugin.
>
> I'm still not convinced why we would need two modules. If we assume that
> Hawkular is similar to a database, in the sense that end users have no
> access to it, then there would be no need for any advanced feature from
> Keycloak. Plain JAAS would suffice.
>
Sent without finishing :)
Another aspect that comes with the removal of the dependency on Keycloak
is surrounding tenancy. We don't have the same requirements as before,
and in the case described above where Hawkular could be seen as a
"database", the tenancy would/should be managed on the user-facing
application.
This means that we'd have a breaking change for components like
Inventory and Metrics, where the tenant is currently the same as the
persona, which in turn is derived from the logged in user (or
organization selected on the account switcher). Not having a tenancy
model anymore means that all users are of the same tenant, so,
components that care about tenancy should be changed.
Note that there are two ways of interpreting "tenancy" here: the first
is about how data is stored, and the second is how data is accessed.
Previously, a tenant would write and read only its own data. Now, tenant
is just another piece of the data, so, components would not actively
check if the data belongs to the current user. We trust that the
user-facing application is performing these checks.
If we don't check that the authenticated user can only access the data he
is entitled to read, it's not good. It's protecting your web application
with client side checks only.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Thomas Segismont
JBoss ON Engineering Team
12:27 p.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
On 18.04.2016 18:43, Thomas Segismont wrote:
If we don't check that the authenticated user can only access the
data
he is entitled to read, it's not good. It's protecting your web
application with client side checks only.
Here's the scenario as I understand it:
jdoe -> Client 1 -> admin1 -> hawkular
jsmith -> Client 1 -> admin1 -> hawkular
jsmith -> Client 2 -> admin2 -> hawkular
On this scheme, an user "jdoe" logs in into "Client 1". This
application
uses "admin1" to talk to our Hawkular backend. Our backends have no idea
about tenants, as it will be managed on "client" applications (ie: MiQ).
I think we could/should have a way to isolate data from
"admin1"/"admin2", but those users are not "tenants" in the
same sense
as we have today, are they?
As I understand it, "jdoe" and "jsmith" might belong to the same
tenant,
but this information is something that is stored inside MiQ, so, not
handled by our backend. Our provider (Ruby gem), however, will have
access to this information.
- Juca.
1:30 p.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
On 18 Apr 2016, at 18:43, Thomas Segismont wrote:
If we don't check that the authenticated user can only access the
data he
is entitled to read, it's not good. It's protecting your web application
with client side checks only.
In the use case where you only have one
user, this probably does not matter too
much.
1:10 p.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
On 18 Apr 2016, at 17:14, Juraci Paixão Kröhling wrote:
Another aspect that comes with the removal of the dependency on
Keycloak
is surrounding tenancy. We don't have the same requirements as before,
and in the case described above where Hawkular could be seen as a
"database", the tenancy would/should be managed on the user-facing
application.
Not sure I completely understand. When e.g. RHQ
uses Postgres, it always logs in as "rhqadmin/rhqadmin".
There is no forwarding of the logged in RHQ-user
to Postgres, but Postgres is always accessed by the
technical user.
This means that we'd have a breaking change for components like
Inventory and Metrics, where the tenant is currently the same as the
persona, which in turn is derived from the logged in user (or
organization selected on the account switcher). Not having a tenancy
model anymore means that all users are of the same tenant, so,
components that care about tenancy should be changed.
Yes. And this is fine, as there is only one user,
which then belongs to a "default tenant".
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
3:36 p.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
On 18.04.2016 20:10, Heiko W.Rupp wrote:
On 18 Apr 2016, at 17:14, Juraci Paixão Kröhling wrote:
> Another aspect that comes with the removal of the dependency on
> Keycloak
> is surrounding tenancy. We don't have the same requirements as before,
> and in the case described above where Hawkular could be seen as a
> "database", the tenancy would/should be managed on the user-facing
> application.
Not sure I completely understand. When e.g. RHQ
uses Postgres, it always logs in as "rhqadmin/rhqadmin".
There is no forwarding of the logged in RHQ-user
to Postgres, but Postgres is always accessed by the
technical user.
I exemplified in another email. Something like this:
jdoe -> Client 1 -> admin1 -> hawkular
jsmith -> Client 1 -> admin1 -> hawkular
jsmith -> Client 2 -> admin2 -> hawkular
Previously, our model was to have "jdoe" talking directly to Hawkular,
and Hawkular Accounts would determine the tenant. Our other Hawkular
components would just need to @Inject a Persona and that persona would
be the tenant.
We have this technical user now, so, we don't necessarily have the
tenant information based on the trusted user data (signed JWT from KC +
data we store ourselves in Cassandra). Accounts cannot inject an
appropriate Persona anymore. We would then need to trust the client (RHQ
in your example) to handle tenancy information, restricting access to
data from tenant A from being seen by tenant B. Or treat tenant data as
just another piece of information, without actively trying to do access
control on our side.
- Juca.
1:06 p.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
On 18 Apr 2016, at 16:57, Juraci Paixão Kröhling wrote:
On 15.04.2016 15:14, Juraci Paixão Kröhling wrote:
> On 15.04.2016 14:43, Heiko W.Rupp wrote:
>> Yes, that *may* require a change. Or not if we e.g. have
>> - accounts-keycloak
>> - accounts-jaas
>> where the latter does the mapping as a jaas provider/plugin.
I'm still not convinced why we would need two modules. If we assume that
Hawkular is similar to a database, in the sense that end users have no
access to it, then there would be no need for any advanced feature from
Keycloak. Plain JAAS would suffice.
We have 2 different use cases:
- Hawkular as we know it. Including KC, Multi-tenancy and the full enchilada
- Hawkular that works like a database for users like ManageIQ, that only need
this one technical user to talk to Hawkular.
3:28 p.m.
New subject: Tenancy model (was Re: Do not depend on Keycloak anymore)
On 18.04.2016 20:06, Heiko W.Rupp wrote:
On 18 Apr 2016, at 16:57, Juraci Paixão Kröhling wrote:
> I'm still not convinced why we would need two modules. If we assume that
> Hawkular is similar to a database, in the sense that end users have no
> access to it, then there would be no need for any advanced feature from
> Keycloak. Plain JAAS would suffice.
We have 2 different use cases:
- Hawkular as we know it. Including KC, Multi-tenancy and the full enchilada
I still don't get why we need this. What's the concrete use case behind
this requirement? Sure, it's nice to have it all and then some, but
there has to be a reason for having this feature, right? :)
KC would be "free" to have, so, I don't mind it much, but multi tenancy
is done by highly customized code in our side, including nested
organization management and custom permission API. If we don't have any
concrete requirements around this, I'd rather remove, so that we can
have better, cleaner and more elegant solutions on other concrete
requirements, like Pavol's Data Mining.
- Hawkular that works like a database for users like ManageIQ, that
only need
this one technical user to talk to Hawkular.
This one I get.
- Juca.
3192
days inactive
3195
days old
9 comments
3 participants
participants (3)
-
Heiko W.Rupp -
Juraci Paixão Kröhling -
Thomas Segismont