12:51 a.m.
Hi,
I need some input on the best way to solve authorization for a retail chain
scenario. Here's the scenario:
A retailer has 10,000 stores and 30,000 users
While each user has a primary store, they can work in other stores in their
region
At his/her primary store UserA (clerk) has the following scopes: POS,
DailyCloseout
For secondary stores, a UserA has only the POS scope
While there are many more scopes, and user roles, the problem to solve is
this multi-tiered permissions structure. UserA's permissions depend on the
store context.
I've set up stores as resources (of type "store"), each resource has a
storeNbr attribute
I've set up scopes of POS, DailyCloseout, SalesReports, etc.
I'm struggling with a clean way to tie a user to his/her "storeX" : [
"scopeA", "scopeB", "scopeC"]. I put this structure in as a
user attribute,
and after mapping it, got it working with a javascript policy
but that's a maintenance nightmare at best.
I can set up roles with names like <storeNbr>.<scopeA>. It's better than
the user attribute route, but still feels like a hack.
I'm guessing I could write a Drools policy that could, using the identity
from the context, read from a database that contains this structure. BUT
this provider is in tech preview / not supported, so I'm not excited about
this route.
Lastly, I guess I could write a custom policy provider.
These last two require me to maintain a separate database (and app to
maintain it), so I'm not thrilled with either of them.
So, what have I missed? Is there an elegant way to solve this?
Thanks for your help!
Scott
--
Scott G. Warren
SUM Global Technology
swarren(a)sumglobal.com
678.469.3455
2:20 p.m.
Hi,
What if you push user's primary store as a claim to your policies and use
this information to decide the scopes he/she has access to?
It could also be useful to avoid creating a resource for each store, so you
could use a single resource and corresponding permission that matches the
store the user is accessing and his primary store (both sent as claims to
your policies).
Regards.
Pedro Igor
On Thu, Dec 27, 2018 at 9:55 PM Warren, Scott <swarren(a)sumglobal.com> wrote:
Hi,
I need some input on the best way to solve authorization for a retail chain
scenario. Here's the scenario:
A retailer has 10,000 stores and 30,000 users
While each user has a primary store, they can work in other stores in their
region
At his/her primary store UserA (clerk) has the following scopes: POS,
DailyCloseout
For secondary stores, a UserA has only the POS scope
While there are many more scopes, and user roles, the problem to solve is
this multi-tiered permissions structure. UserA's permissions depend on the
store context.
I've set up stores as resources (of type "store"), each resource has a
storeNbr attribute
I've set up scopes of POS, DailyCloseout, SalesReports, etc.
I'm struggling with a clean way to tie a user to his/her "storeX" : [
"scopeA", "scopeB", "scopeC"]. I put this structure in as a
user attribute,
and after mapping it, got it working with a javascript policy
but that's a maintenance nightmare at best.
I can set up roles with names like <storeNbr>.<scopeA>. It's better than
the user attribute route, but still feels like a hack.
I'm guessing I could write a Drools policy that could, using the identity
from the context, read from a database that contains this structure. BUT
this provider is in tech preview / not supported, so I'm not excited about
this route.
Lastly, I guess I could write a custom policy provider.
These last two require me to maintain a separate database (and app to
maintain it), so I'm not thrilled with either of them.
So, what have I missed? Is there an elegant way to solve this?
Thanks for your help!
Scott
--
Scott G. Warren
SUM Global Technology
swarren(a)sumglobal.com
678.469.3455
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3:54 p.m.
I like the idea of only creating one store resource! I see the benefit of
pushing the current store as a claim. Is there a way for a policy to get
the request URI to extract the store number (GET /stores/{storeNbr}/sales)?
That seems ideal (provided the storeNbr is in the URI).
I've got the user's primaryStoreNbr as a identityAttribute, so that's no
problem.
Unfortunately, this doesn't solve my real problem, which is storing the
user-to-store-to-scope relationships somehow in Keycloak. While I can do
some common permission consolidation using groups, I've got to have the
following for each of my 30K users so that my policies have the information
they need to make decisions:
{
"user" : "userA", <--identityAttribute
"primaryStoreNbr" : "2001", <--identityAttribute
"storePermissions" : [
{
"storeNbr" : "2001",
"scopes" : [ "POS", "DailyCloseout",
"SalesReports"]
},
{
"storeNbr" : "2002",
"scopes" : [ "POS", "DailyCloseout"]
},
{
"storeNbr" : "2003",
"scopes" : [ "POS"]
},
{
"storeNbr" : "2004",
"scopes" : [ "POS"]
}
]
}
So, do I need to maintain a separate database for (and app to maintain)
this data?
If I'm forced into that :( I can use the identity to do an external DB
lookup for the user permission information. Can I do this with a Drools
rule, or would it be better just to create a custom provider?
5:53 p.m.
Jumped the gun on that last response:
1. I can configure the policy enforcer with claim-information-point to
extract information from the request
2. Assuming I'm correct in that this information is not easily stored in
Keycloak, I need to set up an external Claim Information Point (CIP) either
as an HTTP service or by implementing the CIP SPI.
This seems like the most elegant path, though I really didn't want to
create a separate app and DB to maintain this data.
Any thoughts?
7:18 p.m.
If you use CIP to push the URI [1].
From your example, I understand that by default users have access to
POS.
For the primary store, they can do more. By pushing the URL (or only the
store id), you should be able to differentiate the scopes that should be
granted to primaries vs secondaries stores.
[1]
https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-re...
On Fri, Dec 28, 2018 at 2:57 PM Warren, Scott <swarren(a)sumglobal.com> wrote:
Jumped the gun on that last response:
1. I can configure the policy enforcer with claim-information-point to
extract information from the request
2. Assuming I'm correct in that this information is not easily stored in
Keycloak, I need to set up an external Claim Information Point (CIP) either
as an HTTP service or by implementing the CIP SPI.
This seems like the most elegant path, though I really didn't want to
create a separate app and DB to maintain this data.
Any thoughts?
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
1:01 a.m.
Yeah, I made my original example very simple as I was trying to point out
the multi-tiered permission issue rather than getting bogged down in the
myriad of scopes. Users can have 1-to-many scopes across several stores.
It's not as simple as "if primary store grant this scope set, else grant
that scope set". Life would be a lot easier if it was :)
It sounds like a CIP service accessing an external DB is the 'correct'
answer for this scenario. I see no other clean way to tie
users->stores->scopes.
Thanks for your help!
3:25 p.m.
Hi Warren,
Have you ever thought of implementing stores on the Keycloak side?
Off the top of my head, I can suggest implementing them either as (hierarchical) groups,
or using custom JPA entity [1].
It is not clear if you already have a database with stores or only planning to create and
populate it. In the former case you will need to set up proper synchronization of store
data to Keycloak; in the latter case the need for an external DB will be eliminated.
In both cases you will have to implement Admin Console GUI additions [2] to manage
user-store-scope associations.
The benefits of this approach:
- improved manageability - you manage everything in one place, i.e. Keycloak Admin
Console;
- performance - this will eliminate the need to perform calls to an external system per
each incoming HTTP request, which might have significant performance impact. Keycloak will
already have all the necessary info to evaluate policies.
You can take a look at BeerCloak [3], a complete all-in-one example that contains custom
JPA entity, Admin Console customizations and the necessary wiring. I'm already
thinking about adding an example authorization policy that would involve custom JPA
entities.
To Pedro: I'd also much appreciate your opinion on this approach, so please let me
know what you think.
[1] https://www.keycloak.org/docs/latest/server_development/index.html#_exten...
[2] https://www.keycloak.org/docs/latest/server_development/index.html#_themes
[3] https://github.com/dteleguin/beercloak
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info(a)acutus.pro
On Fri, 2018-12-28 at 19:01 -0500, Warren, Scott wrote:
Yeah, I made my original example very simple as I was trying to point
out
the multi-tiered permission issue rather than getting bogged down in the
myriad of scopes. Users can have 1-to-many scopes across several stores.
It's not as simple as "if primary store grant this scope set, else grant
that scope set". Life would be a lot easier if it was :)
It sounds like a CIP service accessing an external DB is the 'correct'
answer for this scenario. I see no other clean way to tie
users->stores->scopes.
Thanks for your help!
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3:48 p.m.
On Fri, Jan 4, 2019 at 12:25 PM Dmitry Telegin <dt(a)acutus.pro> wrote:
Hi Warren,
Have you ever thought of implementing stores on the Keycloak side?
Off the top of my head, I can suggest implementing them either as
(hierarchical) groups, or using custom JPA entity [1].
It is not clear if you already have a database with stores or only
planning to create and populate it. In the former case you will need to set
up proper synchronization of store data to Keycloak; in the latter case the
need for an external DB will be eliminated.
In both cases you will have to implement Admin Console GUI additions [2]
to manage user-store-scope associations.
The benefits of this approach:
- improved manageability - you manage everything in one place, i.e.
Keycloak Admin Console;
- performance - this will eliminate the need to perform calls to an
external system per each incoming HTTP request, which might have
significant performance impact. Keycloak will already have all the
necessary info to evaluate policies.
You can take a look at BeerCloak [3], a complete all-in-one example that
contains custom JPA entity, Admin Console customizations and the necessary
wiring. I'm already thinking about adding an example authorization policy
that would involve custom JPA entities.
To Pedro: I'd also much appreciate your opinion on this approach, so
please let me know what you think.
That would be nice and maybe could help us with an RFE still open around a
"Resource SPI". Depending on what you are planning, your proposal could
even be much more powerful as it would imply access to claims not only
specific to resources but anything available from your database.
[1]
https://www.keycloak.org/docs/latest/server_development/index.html#_exten...
[2]
https://www.keycloak.org/docs/latest/server_development/index.html#_themes
[3] https://github.com/dteleguin/beercloak
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info(a)acutus.pro
On Fri, 2018-12-28 at 19:01 -0500, Warren, Scott wrote:
> Yeah, I made my original example very simple as I was trying to point out
> the multi-tiered permission issue rather than getting bogged down in the
> myriad of scopes. Users can have 1-to-many scopes across several stores.
> It's not as simple as "if primary store grant this scope set, else grant
> that scope set". Life would be a lot easier if it was :)
> It sounds like a CIP service accessing an external DB is the 'correct'
> answer for this scenario. I see no other clean way to tie
> users->stores->scopes.
> Thanks for your help!
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
4:08 p.m.
Hi Pedro, thanks for your input,
Is this issue related to the "Resource SPI" you've mentioned?
https://issues.jboss.org/browse/KEYCLOAK-4905
Dmitry
On Fri, 2019-01-04 at 12:48 -0200, Pedro Igor Silva wrote:
> On Fri, Jan 4, 2019 at 12:25 PM Dmitry Telegin <dt(a)acutus.pro> wrote:
> Hi Warren,
>
> Have you ever thought of implementing stores on the Keycloak side?
>
> Off the top of my head, I can suggest implementing them either as (hierarchical)
groups, or using custom JPA entity [1].
>
> It is not clear if you already have a database with stores or only planning to
create and populate it. In the former case you will need to set up proper synchronization
of store data to Keycloak; in the latter case the need for an external DB will be
eliminated.
> In both cases you will have to implement Admin Console GUI additions [2] to manage
user-store-scope associations.
>
> The benefits of this approach:
> - improved manageability - you manage everything in one place, i.e. Keycloak Admin
Console;
> - performance - this will eliminate the need to perform calls to an external system
per each incoming HTTP request, which might have significant performance impact. Keycloak
will already have all the necessary info to evaluate policies.
>
> You can take a look at BeerCloak [3], a complete all-in-one example that contains
custom JPA entity, Admin Console customizations and the necessary wiring. I'm already
thinking about adding an example authorization policy that would involve custom JPA
entities.
>
> To Pedro: I'd also much appreciate your opinion on this approach, so please let
me know what you think.
That would be nice and maybe could help us with an RFE still open around a "Resource
SPI". Depending on what you are planning, your proposal could even be much more
powerful as it would imply access to claims not only specific to resources but anything
available from your database.
> [1]
https://www.keycloak.org/docs/latest/server_development/index.html#_exten...
> [2] https://www.keycloak.org/docs/latest/server_development/index.html#_themes
> [3] https://github.com/dteleguin/beercloak
>
> Dmitry Telegin
> CTO, Acutus s.r.o.
> Keycloak Consulting and Training
>
> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> +42 (022) 888-30-71
> E-mail: info(a)acutus.pro
>
> On Fri, 2018-12-28 at 19:01 -0500, Warren, Scott wrote:
> > Yeah, I made my original example very simple as I was trying to point out
> > the multi-tiered permission issue rather than getting bogged down in the
> > myriad of scopes. Users can have 1-to-many scopes across several stores.
> > It's not as simple as "if primary store grant this scope set, else
grant
> > that scope set". Life would be a lot easier if it was :)
> > It sounds like a CIP service accessing an external DB is the 'correct'
> > answer for this scenario. I see no other clean way to tie
> > users->stores->scopes.
> > Thanks for your help!
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
4:46 p.m.
Yeah, it is.
On Fri, Jan 4, 2019 at 1:08 PM Dmitry Telegin <dt(a)acutus.pro> wrote:
Hi Pedro, thanks for your input,
Is this issue related to the "Resource SPI" you've mentioned?
https://issues.jboss.org/browse/KEYCLOAK-4905
Dmitry
On Fri, 2019-01-04 at 12:48 -0200, Pedro Igor Silva wrote:
>
> > On Fri, Jan 4, 2019 at 12:25 PM Dmitry Telegin <dt(a)acutus.pro> wrote:
> > Hi Warren,
> >
> > Have you ever thought of implementing stores on the Keycloak side?
> >
> > Off the top of my head, I can suggest implementing them either as
(hierarchical) groups, or using custom JPA entity [1].
> >
> > It is not clear if you already have a database with stores or only
planning to create and populate it. In the former case you will need to set
up proper synchronization of store data to Keycloak; in the latter case the
need for an external DB will be eliminated.
> > In both cases you will have to implement Admin Console GUI additions
[2] to manage user-store-scope associations.
> >
> > The benefits of this approach:
> > - improved manageability - you manage everything in one place, i.e.
Keycloak Admin Console;
> > - performance - this will eliminate the need to perform calls to an
external system per each incoming HTTP request, which might have
significant performance impact. Keycloak will already have all the
necessary info to evaluate policies.
> >
> > You can take a look at BeerCloak [3], a complete all-in-one example
that contains custom JPA entity, Admin Console customizations and the
necessary wiring. I'm already thinking about adding an example
authorization policy that would involve custom JPA entities.
> >
> > To Pedro: I'd also much appreciate your opinion on this approach, so
please let me know what you think.
>
> That would be nice and maybe could help us with an RFE still open around
a "Resource SPI". Depending on what you are planning, your proposal could
even be much more powerful as it would imply access to claims not only
specific to resources but anything available from your database.
>
> > [1]
https://www.keycloak.org/docs/latest/server_development/index.html#_exten...
> > [2]
https://www.keycloak.org/docs/latest/server_development/index.html#_themes
> > [3] https://github.com/dteleguin/beercloak
> >
> > Dmitry Telegin
> > CTO, Acutus s.r.o.
> > Keycloak Consulting and Training
> >
> > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> > +42 (022) 888-30-71
> > E-mail: info(a)acutus.pro
> >
> > On Fri, 2018-12-28 at 19:01 -0500, Warren, Scott wrote:
> > > Yeah, I made my original example very simple as I was trying to
point out
> > > the multi-tiered permission issue rather than getting bogged down in
the
> > > myriad of scopes. Users can have 1-to-many scopes across several
stores.
> > > It's not as simple as "if primary store grant this scope set,
else
grant
> > > that scope set". Life would be a lot easier if it was :)
> > > It sounds like a CIP service accessing an external DB is the
'correct'
> > > answer for this scenario. I see no other clean way to tie
> > > users->stores->scopes.
> > > Thanks for your help!
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
4:28 p.m.
Hi Dmitry,
I really like that idea. Thanks for the suggestion. I'll give it a try.
Thanks,
Scott
On Fri, Jan 4, 2019 at 9:25 AM Dmitry Telegin <dt(a)acutus.pro> wrote:
Hi Warren,
Have you ever thought of implementing stores on the Keycloak side?
Off the top of my head, I can suggest implementing them either as
(hierarchical) groups, or using custom JPA entity [1].
It is not clear if you already have a database with stores or only
planning to create and populate it. In the former case you will need to set
up proper synchronization of store data to Keycloak; in the latter case the
need for an external DB will be eliminated.
In both cases you will have to implement Admin Console GUI additions [2]
to manage user-store-scope associations.
The benefits of this approach:
- improved manageability - you manage everything in one place, i.e.
Keycloak Admin Console;
- performance - this will eliminate the need to perform calls to an
external system per each incoming HTTP request, which might have
significant performance impact. Keycloak will already have all the
necessary info to evaluate policies.
You can take a look at BeerCloak [3], a complete all-in-one example that
contains custom JPA entity, Admin Console customizations and the necessary
wiring. I'm already thinking about adding an example authorization policy
that would involve custom JPA entities.
To Pedro: I'd also much appreciate your opinion on this approach, so
please let me know what you think.
[1]
https://www.keycloak.org/docs/latest/server_development/index.html#_exten...
[2]
https://www.keycloak.org/docs/latest/server_development/index.html#_themes
[3] https://github.com/dteleguin/beercloak
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info(a)acutus.pro
On Fri, 2018-12-28 at 19:01 -0500, Warren, Scott wrote:
> Yeah, I made my original example very simple as I was trying to point out
> the multi-tiered permission issue rather than getting bogged down in the
> myriad of scopes. Users can have 1-to-many scopes across several stores.
> It's not as simple as "if primary store grant this scope set, else grant
> that scope set". Life would be a lot easier if it was :)
> It sounds like a CIP service accessing an external DB is the 'correct'
> answer for this scenario. I see no other clean way to tie
> users->stores->scopes.
> Thanks for your help!
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Scott G. Warren
SUM Global Technology
swarren(a)sumglobal.com
678.469.3455
2190
days inactive
2198
days old
10 comments
3 participants
participants (3)
-
Dmitry Telegin -
Pedro Igor Silva -
Warren, Scott