[keycloak-user] Fwd: Multi-tiered Permissions

[Pedro Igor Silva]

Yeah, it is.

On Fri, Jan 4, 2019 at 1:08 PM Dmitry Telegin <dt at 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 at 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#_extensions_jpa
> > > [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 at 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 at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
>