11:22 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
After the demo, I was looking for ways to improve the "realm selection
modal", but I keep hitting a problem with the definition of a
tenant/realm.
Taking Keycloak out of the context for a while, I'd like to get *our*
definition of tenant to be made. After that, I can check if we can use
Keycloak as part of the authorization for this scenario (KC will
probably still be part of the authentication, though).
One possible solution is to have "users" and "organizations", a la
Github. Users can be part of zero or more organizations and
organizations have one or more members. Data (git repos or resources)
belongs to either an user or an organization.
For this solution, here's how I see it working on different scenarios:
- - standalone/hobby user: isn't a member of any organization, but have
a few resources to manage. A sample curl call:
- -> http://user:password@hawkular/metrics
all metrics for all resources owned by the user's main account
- -> http://user:password@hawkular/resource/{resourceId}/metrics
all metrics for this specific resource, which should belong to the
main account
- - user who creates/manages one or more organizations: can either have
resources on the main account (like standalone) or have resources
belonging to an organization. Sample curl call:
- -> http://user:password@hawkular/metrics
all metrics for all resources owned by the user's main account *or*
owned by organizations where this user is a member of.
- -> http://user:password@hawkular/resource/{resourceId}/metrics
all metrics for this specific resource, if the resource belongs to
the user or to an organization where the user is a member of
For this scenario, I think the UI could be built with a "context
switcher". This way, the user would have access to a dashboard with
resources from his main account and could switch to a dashboard with
resources from an organization. The backend, though, would not have
such a notion of "context". Either the user has access to the resource
or not (via the main account or via an organization).
Putting Keycloak back in context: for this kind of scenario, we would
have only one Keycloak realm, so, all users would be in one big realm.
All of the authorization would be made on our backend(s). Upon
registration (via Keycloak), an user doesn't belongs to any
organization. In the future, we can consume some extra LDAP data from
Keycloak, to auto assign users to some organizations, if desirable.
The main disadvantage of this is that we have to also care about the
authorization, as we cannot rely on permission data coming from Keycloak.
The main advantage is that we get a behavior that is custom tailored
to our use case.
Thoughts?
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUymw8AAoJECKM1e+fkPrX9KQH/A2O1pcV+cO3mu7PPV5aWq/v
9Ke+xlm+2hutMVKned5RGld2JD47pqTqdj6WBsLqu04AcntUrc46Vt8gnHCGrst+
FlYPsvlhb/tkN3Ddg4UMfspn5uar7uaSg2namTtSz3A/DDjQkmxqBBCUqtLgFaAc
NDaV/XkDrPCBbbNOHN11GLBV8WpFM6g5JeiaPfHWROGTifQCJU52ZEgPj0pbtGL9
NqLjOF2ekrnhxVNH/PqP2akN0bzWK6Bo2i2SMgNILZEDVQyMlTA1w1hCEcn/35oG
wHCOsGFb2RUJyqGgWqyqoxqsKBgOErzfGUhwQ4VEpU15Cvoh3HyGrEtHQCqFWzI=
=IfUo
-----END PGP SIGNATURE-----
8:37 a.m.
Tough subject and we can hardly predict what users will really need.
I hope we can keep it simple for now. We may have to revisit later.
Can we say that:
Step 1: resources belong to a user and only him has access
Step 2: resources can be shared with a group or a specific user by the
owner (who can grant "write access" to the group or specific users)
IMO this is already quite flexible, simple from a user perspective but
already complex enough to handle initially. (A user who have read access
should still be able to create alerts for this resource...) We'll have
to think about what happens to orphans resources (owner gets deleted)
and likely other corner cases and optimizations (like the switcher you
mentioned or like in Google drive, sharing with me doesn't mean it will
mess with my documents unless I want to copy it over.)
I think it maps with what you described.
Thomas
On 01/29/2015 06:22 PM, Juraci Paixão Kröhling wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
After the demo, I was looking for ways to improve the "realm selection
modal", but I keep hitting a problem with the definition of a
tenant/realm.
Taking Keycloak out of the context for a while, I'd like to get *our*
definition of tenant to be made. After that, I can check if we can use
Keycloak as part of the authorization for this scenario (KC will
probably still be part of the authentication, though).
One possible solution is to have "users" and "organizations", a la
Github. Users can be part of zero or more organizations and
organizations have one or more members. Data (git repos or resources)
belongs to either an user or an organization.
For this solution, here's how I see it working on different scenarios:
- - standalone/hobby user: isn't a member of any organization, but have
a few resources to manage. A sample curl call:
- -> http://user:password@hawkular/metrics
all metrics for all resources owned by the user's main account
- -> http://user:password@hawkular/resource/{resourceId}/metrics
all metrics for this specific resource, which should belong to the
main account
- - user who creates/manages one or more organizations: can either have
resources on the main account (like standalone) or have resources
belonging to an organization. Sample curl call:
- -> http://user:password@hawkular/metrics
all metrics for all resources owned by the user's main account *or*
owned by organizations where this user is a member of.
- -> http://user:password@hawkular/resource/{resourceId}/metrics
all metrics for this specific resource, if the resource belongs to
the user or to an organization where the user is a member of
For this scenario, I think the UI could be built with a "context
switcher". This way, the user would have access to a dashboard with
resources from his main account and could switch to a dashboard with
resources from an organization. The backend, though, would not have
such a notion of "context". Either the user has access to the resource
or not (via the main account or via an organization).
Putting Keycloak back in context: for this kind of scenario, we would
have only one Keycloak realm, so, all users would be in one big realm.
All of the authorization would be made on our backend(s). Upon
registration (via Keycloak), an user doesn't belongs to any
organization. In the future, we can consume some extra LDAP data from
Keycloak, to auto assign users to some organizations, if desirable.
The main disadvantage of this is that we have to also care about the
authorization, as we cannot rely on permission data coming from Keycloak.
The main advantage is that we get a behavior that is custom tailored
to our use case.
Thoughts?
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUymw8AAoJECKM1e+fkPrX9KQH/A2O1pcV+cO3mu7PPV5aWq/v
9Ke+xlm+2hutMVKned5RGld2JD47pqTqdj6WBsLqu04AcntUrc46Vt8gnHCGrst+
FlYPsvlhb/tkN3Ddg4UMfspn5uar7uaSg2namTtSz3A/DDjQkmxqBBCUqtLgFaAc
NDaV/XkDrPCBbbNOHN11GLBV8WpFM6g5JeiaPfHWROGTifQCJU52ZEgPj0pbtGL9
NqLjOF2ekrnhxVNH/PqP2akN0bzWK6Bo2i2SMgNILZEDVQyMlTA1w1hCEcn/35oG
wHCOsGFb2RUJyqGgWqyqoxqsKBgOErzfGUhwQ4VEpU15Cvoh3HyGrEtHQCqFWzI=
=IfUo
-----END PGP SIGNATURE-----
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:55 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/30/2015 03:37 PM, Thomas Heute wrote:
I hope we can keep it simple for now. We may have to revisit
later.
Can we say that: Step 1: resources belong to a user and only him
has access Step 2: resources can be shared with a group or a
specific user by the owner (who can grant "write access" to the
group or specific users)
IMO this is already quite flexible, simple from a user perspective
but already complex enough to handle initially. (A user who have
read access should still be able to create alerts for this
resource...) We'll have to think about what happens to orphans
resources (owner gets deleted) and likely other corner cases and
optimizations (like the switcher you mentioned or like in Google
drive, sharing with me doesn't mean it will mess with my documents
unless I want to copy it over.)
Alright, so, this means also that authentication is done by KC, and
authorization is done by the application. I think it's the safest
route for the beginning.
This effectively means that KC will have only one "hawkular" realm and
all users will be inside of it. The notion of "tenant" is then built
on our side. In the end, it's the simplest form of KC and it also
gives us self-registration for free.
Next step is, then, hawt.io with KC :-)
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUy6lUAAoJECKM1e+fkPrX+qMH/ReUnlHY1l4OmvGn9yy4TVcw
gDpqj13OY4bAqdm/Nb6a3jVxs/GN/Bwpucrz/0NBd8FueexnNz162gjsoBiZCARF
5/hnKOpddqhCyhOm4N0s+UAE7xNXViesbbdcZsCh/LeSdROlpaAvKmkOpXvwr8Y/
ZwxyJkCFejpy77nrgTGfi2Aj6fK4XtNm57Ifm3V8JlX3XcP0vDKOv9BMpmkW04d9
sV6t2p98sGeFkO0zui4zuYSPO8DVtsHTID35m2THSlUiFnjj02GpXfnCNDNF3EMB
vae0wW5Z0jCJ6QTU/LprXwmNwq579bwUQvQvfipzNIX2OSlXJ6ytzhwEWREQvAc=
=Tha0
-----END PGP SIGNATURE-----
10 a.m.
Hi,
One possible solution is to have "users" and
"organizations", a la
Github. Users can be part of zero or more organizations and
organizations have one or more members. Data (git repos or resources)
belongs to either an user or an organization.
I think I like this idea.
- -> http://user:password@hawkular/resource/{resourceId}/metrics
all metrics for this specific resource, if the resource belongs to
the user or to an organization where the user is a member of
How would we model the user / org stuff? Well, that could probably
just become a part of inventory
Question is though: if a user has his own pet server and works as
part of an org. Do we want to prevent "leaking" org data to the private
project? Or is that purely up to the user?
For this scenario, I think the UI could be built with a
"context
switcher". This way, the user would have access to a dashboard with
resources from his main account and could switch to a dashboard with
resources from an organization. The backend, though, would not have
such a notion of "context". Either the user has access to the resource
or not (via the main account or via an organization).
Wouldn't the backend still need to know the context - and if only for
performance reason when the user wants to only see his personal resources?
The main disadvantage of this is that we have to also care about the
authorization, as we cannot rely on permission data coming from Keycloak.
Well, I guess a good deal of authorization needs to be done in some custom
code anyway and would not be covered by stock-JAAS, so it may not be that bad.
Heiko
10:56 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/04/2015 05:00 PM, Heiko W.Rupp wrote:
How would we model the user / org stuff? Well, that could probably
just become a part of inventory
I'd say that this mapping should be part of a new module, with an API
being provided to other modules.
The model would be something like this:
* Metric belongs to Owner.
* Organization belongs to Owner.
* Owner is an interface, implemented by User and Organization.
* User can be the owner of one or more organizations.
This way, organizations can be owned by other organizations. Not sure
if this will work, though. I'm starting to work on this right now on a
new module (hawkular-accounts).
Question is though: if a user has his own pet server and works as
part of an org. Do we want to prevent "leaking" org data to the
private project? Or is that purely up to the user?
If an user makes a REST call to retrieve all metrics that he has
access to, I'd expect that he'd receive both metrics for his pet
projects and metrics for organizations he's part of.
Wouldn't the backend still need to know the context - and if
only
for performance reason when the user wants to only see his personal
resources?
The backend *needs* to check if the current user has access to the
resource. Other than that, I'd say it's up to the individual
components (alerts, metrics, inventory, ...) what/how they want to
expose data to the consumers. For instance, metrics might want to have
the following REST endpoints:
/{owner}/metrics
--> all metrics owned by "owner" (organization or user)
/metrics
--> all metrics to which the current user has access to
/metric/{metricId}
--> a specific metric, as long as the user has access to it
So, on the metrics backend and UI, they might decide to always require
an owner (like, with a context switcher on the UI), or to provide both
endpoints.
Well, I guess a good deal of authorization needs to be done in some
custom code anyway and would not be covered by stock-JAAS, so it
may not be that bad.
Indeed. The more I think about this problem, the more I'm convinced
that we should be handling the authorization ourselves.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU0k85AAoJECKM1e+fkPrXMUEH/jRCxeAuERAP761WZQmPlUvH
GItzQRMPBW+M+CHEdzYJGErCARrJeWPSOjtMp/xKz+W8Iw7SBMH/KDlfDDILooFk
JEXKSdITJIGHNSE+SQ9A+33LfVYUM2CfS4oeWgOmOOmemKP1HTO7z479qljXUPDN
NLn0pSSynZhONMH3l5M1IEuCthCFHqrPzzWBpmhrmL8+rhBkrm5tQU4IjfFGERcP
VmFiFut7tJreq2Yr3kqPoidJiHs37ZFlQzfZmbwcdDjBtO+m/uz9g3pp49JhHAKY
eAAdb4mhNBu8hrYLm1fx0jwBzyG6R7nNQUO9O+aTi7ODd38BR4HJE76H6TjBQqE=
=oTDA
-----END PGP SIGNATURE-----
5:54 a.m.
Am 04.02.2015 um 17:56 schrieb Juraci Paixão Kröhling
<jpkroehling(a)redhat.com>:
This way, organizations can be owned by other organizations. Not sure
I think that makes sense and follows the idea of acme.org and foo.acme.org, bar.acme.org
if this will work, though. I'm starting to work on this right now
on a
new module (hawkular-accounts).
Once you have a little bit of it : can you make it publicly available?
Perhaps including some drawings :)
If an user makes a REST call to retrieve all metrics that he has
access to, I'd expect that he'd receive both metrics for his pet
projects and metrics for organizations he's part of.
Now suppose that user creates a dashboard with (graphs of) org resources and pet
resources
and shares (=clones + distributes) that to another user. I guess the dashboard would
then show those pet resources in a bad state (no data, or worse). Or how could
we deal with that?
The backend *needs* to check if the current user has access to the
resource. Other than that, I'd say it's up to the individual
components (alerts, metrics, inventory, ...) what/how they want to
expose data to the consumers. For instance, metrics might want to have
Well, we should try to be consistent?
the following REST endpoints:
/{owner}/metrics
--> all metrics owned by "owner" (organization or user)
/metrics
--> all metrics to which the current user has access to
The difference between the above is that the first is "org XOR user"
resources not "union-or"? While the 2nd one is (org || user) - right?
Thanks
Heiko
6:19 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/06/2015 12:54 PM, Heiko W.Rupp wrote:
Yes. We'll need to take a closer look once it gets ready, to see if
the rules I made up make sense. For instance, are users of
bar.acme.org supposed to access acme.org? Or just users which are
directly assigned to acme.org? This question can be answered later.
> if this will work, though. I'm starting to work on this right
now
> on a new module (hawkular-accounts).
Once you have a little bit of it : can you make it publicly
available? Perhaps including some drawings :)
Sure, I'm almost done with the basics of the backend and should start
with the UI (with hawt.io) this afternoon. Let's see if I have
something to show next week during a water cooler.
> If an user makes a REST call to retrieve all metrics that he has
> access to, I'd expect that he'd receive both metrics for his pet
> projects and metrics for organizations he's part of.
Now suppose that user creates a dashboard with (graphs of) org
resources and pet resources and shares (=clones + distributes) that
to another user. I guess the dashboard would then show those pet
resources in a bad state (no data, or worse). Or how could we deal
with that?
Not sure I follow. You mean the case where I share a graph of a
resource of mine with you? I suppose that this graph would have a
unique URL (/graph/{graphId}), and I could create an organization to
share this graph. Would that work? Another solution could be to tell
the user "this unique URL is unsecured, anyone you share this with
will have access, no matter what".
> The backend *needs* to check if the current user has access to
> the resource. Other than that, I'd say it's up to the individual
> components (alerts, metrics, inventory, ...) what/how they want
> to expose data to the consumers. For instance, metrics might want
> to have
Well, we should try to be consistent?
Absolutely. But in the end, it's a decision of the component itself.
If there's a situation where breaking consistency makes sense, it's
still possible from the auth/authz perspective.
> the following REST endpoints:
>
> /{owner}/metrics --> all metrics owned by "owner" (organization
> or user)
>
> /metrics --> all metrics to which the current user has access to
>
The difference between the above is that the first is "org XOR
user" resources not "union-or"? While the 2nd one is (org || user)
- right?
Yes, I'd expect metrics to return only the metrics for a specific
owner on the first case, and all metrics in the second case.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU1LFnAAoJECKM1e+fkPrXrRMH/3bDZH5vUgMcyC8Yw0ULk57I
O2jimv5GrH/xMEpWke1f4GbSrEnqYeNIfH9etO8bTgWNMerjKiwE/jvcOB0rMvq2
TKQm3JOKAokjPowQVaH8o2oHZeddIWoS6P2P6t6W16SztJh+Yp6wl2pe0jMugpvD
JAiSzZ+mhPsm82ICLaB+430cTi3WXwtW/UQhCVx1IHzddEgZG0NTWCFdMP38QafN
tXnLqkvYct2uF9egDjXpijt64S43ayT3dPKapim6FJsBI4uzLtbrULiRm2XL6agN
Ysj9KZ4f/z0ZFEIGV2rLVXbh5tt8fpZBYmWBd1ftr9ZZX80blBnAerG6d5RA0ts=
=wuu9
-----END PGP SIGNATURE-----
3588
days inactive
3596
days old
6 comments
3 participants
participants (3)
-
Heiko W.Rupp -
Juraci Paixão Kröhling -
Thomas Heute