3:11 p.m.
I find creating role policies as cumbersome. Also, how is the admin
supposed to know if a policy with a specific role has already been
created or not? Maybe policies can have DENY and PERMIT role lists.
when creating permissions you can just pick roles to add/remove to the
permission. I think the most used, most common case (90% of the time?)
will be assigning role permissions to resources so we should make it as
easy as possible. Both within the admin UI and APIs. Thoughts?
Bill
4:21 p.m.
I think you are exploring now a new way of seeing things.
Today we have a flexible permissioning model where you define independent
policies to build these permissions or even build other policies. Where you
may have a library of policies, reuse these policies across different
permissions, etc.
What you are proposing, if I understood correctly, and that is what I meant
by the "new way of seeing things", is also allow users to create
permissions more easily without necessarily having to create policies. In
other words, we would be providing additional permission types (in addition
to resource/scope) for some very common use cases like the one you
mentioned where you just need a white/blacklist of roles.
Does it make sense ?
On Sat, Apr 1, 2017 at 10:11 AM, Bill Burke <bburke(a)redhat.com> wrote:
I find creating role policies as cumbersome. Also, how is the admin
supposed to know if a policy with a specific role has already been
created or not? Maybe policies can have DENY and PERMIT role lists.
when creating permissions you can just pick roles to add/remove to the
permission. I think the most used, most common case (90% of the time?)
will be assigning role permissions to resources so we should make it as
easy as possible. Both within the admin UI and APIs. Thoughts?
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:31 p.m.
Yes, because I think the most common permission will be 100% role based.
On 4/1/17 10:21 AM, Pedro Igor Silva wrote:
I think you are exploring now a new way of seeing things.
Today we have a flexible permissioning model where you define
independent policies to build these permissions or even build other
policies. Where you may have a library of policies, reuse these
policies across different permissions, etc.
What you are proposing, if I understood correctly, and that is what I
meant by the "new way of seeing things", is also allow users to create
permissions more easily without necessarily having to create policies.
In other words, we would be providing additional permission types (in
addition to resource/scope) for some very common use cases like the
one you mentioned where you just need a white/blacklist of roles.
Does it make sense ?
On Sat, Apr 1, 2017 at 10:11 AM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
I find creating role policies as cumbersome. Also, how is the admin
supposed to know if a policy with a specific role has already been
created or not? Maybe policies can have DENY and PERMIT role lists.
when creating permissions you can just pick roles to add/remove to the
permission. I think the most used, most common case (90% of the
time?)
will be assigning role permissions to resources so we should make
it as
easy as possible. Both within the admin UI and APIs. Thoughts?
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
4:40 p.m.
What about creating a new permission type called "Roles" or whatever, which
provides a single page from where you can select:
* Resource
* Scopes
* Whitelis of Roles
* Blacklist of Roles
* Policies (in case you want to also apply any other policy in addition to
both white/blacklist)
?
On Sat, Apr 1, 2017 at 11:31 AM, Bill Burke <bburke(a)redhat.com> wrote:
Yes, because I think the most common permission will be 100% role
based.
On 4/1/17 10:21 AM, Pedro Igor Silva wrote:
I think you are exploring now a new way of seeing things.
Today we have a flexible permissioning model where you define independent
policies to build these permissions or even build other policies. Where you
may have a library of policies, reuse these policies across different
permissions, etc.
What you are proposing, if I understood correctly, and that is what I
meant by the "new way of seeing things", is also allow users to create
permissions more easily without necessarily having to create policies. In
other words, we would be providing additional permission types (in addition
to resource/scope) for some very common use cases like the one you
mentioned where you just need a white/blacklist of roles.
Does it make sense ?
On Sat, Apr 1, 2017 at 10:11 AM, Bill Burke <bburke(a)redhat.com> wrote:
> I find creating role policies as cumbersome. Also, how is the admin
> supposed to know if a policy with a specific role has already been
> created or not? Maybe policies can have DENY and PERMIT role lists.
> when creating permissions you can just pick roles to add/remove to the
> permission. I think the most used, most common case (90% of the time?)
> will be assigning role permissions to resources so we should make it as
> easy as possible. Both within the admin UI and APIs. Thoughts?
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
5:27 p.m.
Maybe don't need a whitelist and blacklist. Just a list. The decision
strategy can decide stuff.
On 4/1/17 10:40 AM, Pedro Igor Silva wrote:
What about creating a new permission type called "Roles" or
whatever,
which provides a single page from where you can select:
* Resource
* Scopes
* Whitelis of Roles
* Blacklist of Roles
* Policies (in case you want to also apply any other policy in
addition to both white/blacklist)
?
On Sat, Apr 1, 2017 at 11:31 AM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Yes, because I think the most common permission will be 100% role
based.
On 4/1/17 10:21 AM, Pedro Igor Silva wrote:
> I think you are exploring now a new way of seeing things.
>
> Today we have a flexible permissioning model where you define
> independent policies to build these permissions or even build
> other policies. Where you may have a library of policies, reuse
> these policies across different permissions, etc.
>
> What you are proposing, if I understood correctly, and that is
> what I meant by the "new way of seeing things", is also allow
> users to create permissions more easily without necessarily
> having to create policies. In other words, we would be providing
> additional permission types (in addition to resource/scope) for
> some very common use cases like the one you mentioned where you
> just need a white/blacklist of roles.
>
> Does it make sense ?
>
> On Sat, Apr 1, 2017 at 10:11 AM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> I find creating role policies as cumbersome. Also, how is
> the admin
> supposed to know if a policy with a specific role has already
> been
> created or not? Maybe policies can have DENY and PERMIT role
> lists.
> when creating permissions you can just pick roles to
> add/remove to the
> permission. I think the most used, most common case (90% of
> the time?)
> will be assigning role permissions to resources so we should
> make it as
> easy as possible. Both within the admin UI and APIs. Thoughts?
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
2575
days inactive
2575
days old
4 comments
2 participants
participants (2)
-
Bill Burke -
Pedro Igor Silva