<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-04-18 17:14 GMT+02:00 Juraci Paixão Kröhling <span dir="ltr"><<a href="mailto:jpkroehling@redhat.com" target="_blank">jpkroehling@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 18.04.2016 16:57, Juraci Paixão Kröhling wrote:<br>
> On 15.04.2016 15:14, Juraci Paixão Kröhling wrote:<br>
>> On 15.04.2016 14:43, Heiko W.Rupp wrote:<br>
>>> Yes, that *may* require a change. Or not if we e.g. have<br>
>>> - accounts-keycloak<br>
>>> - accounts-jaas<br>
>>> where the latter does the mapping as a jaas provider/plugin.<br>
><br>
> I'm still not convinced why we would need two modules. If we assume that<br>
> Hawkular is similar to a database, in the sense that end users have no<br>
> access to it, then there would be no need for any advanced feature from<br>
> Keycloak. Plain JAAS would suffice.<br>
><br>
<br>
</span>Sent without finishing :)<br>
<br>
Another aspect that comes with the removal of the dependency on Keycloak<br>
is surrounding tenancy. We don't have the same requirements as before,<br>
and in the case described above where Hawkular could be seen as a<br>
"database", the tenancy would/should be managed on the user-facing<br>
application.<br>
<br>
This means that we'd have a breaking change for components like<br>
Inventory and Metrics, where the tenant is currently the same as the<br>
persona, which in turn is derived from the logged in user (or<br>
organization selected on the account switcher). Not having a tenancy<br>
model anymore means that all users are of the same tenant, so,<br>
components that care about tenancy should be changed.<br>
<br>
Note that there are two ways of interpreting "tenancy" here: the first<br>
is about how data is stored, and the second is how data is accessed.<br>
Previously, a tenant would write and read only its own data. Now, tenant<br>
is just another piece of the data, so, components would not actively<br>
check if the data belongs to the current user. We trust that the<br>
user-facing application is performing these checks.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
- Juca.<br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Thomas Segismont<br></div>JBoss ON Engineering Team<br></div></div>
</div></div>