On 19 July 2016 at 14:41, Pedro Igor Silva <psilva(a)redhat.com> wrote:
----- Original Message -----
> From: "Stian Thorgersen" <sthorger(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>, "keycloak-dev"
<
keycloak-dev(a)lists.jboss.org>
> Sent: Tuesday, July 19, 2016 5:02:48 AM
> Subject: Feedback on authz services
>
> Things we could add:
> ----------------------------
>
> * Add policy enforcement support to Keycloak Proxy
>
> * Node.js adapter
https://issues.jboss.org/browse/KEYCLOAK-3333
https://issues.jboss.org/browse/KEYCLOAK-3334
>
>
> Comments:
> ---------------
>
> * Docs - added a few comments (
>
https://www.gitbook.com/book/keycloak/authorization-services-guide/discus...
> )
Will look at that.
>
> * JS Policy - I found it hard to figure out how to write these,
especially
> since the docs are showing Java interfaces
Basically, we publish instances of those interfaces to the JS engine. That
is why I did that way. If you know the contract, than you can start writing
your policies.
But I understand your point, I'm going to improve that doc and make it
more JS-friendly.
>
> * Attribute based policy - We don't seem to have a simple attribute based
> policy, should we not have this?
Yes, that makes sense.
https://issues.jboss.org/browse/KEYCLOAK-3335
>
> * Default policy (only from realm) - This default makes no sense. I'd
> suggest removing or replacing with something that's more obvious like
> "require user to have an email set"
I was thinking about that and, IMO, the rule you suggested is not the best
way to go. As you know, users may not have an e-mail set, thus they won't
be able to access applications protected with our policy enforcer. I think
we can just have a simple policy that always perform a grant.
The motivations behind that policy are:
* Show that you can use rule-based policies
* Show that we have an API that you can use to build these policies
* Show that you can perform decisions based on attributes from both
environment and identity (ABAC)
Although redundant, that policy is a good start point to understand some
capabilities we provide.
Current one isn't just redundant it's also confusing and slightly broken
(realm name alone isn't sufficient as it could have been the same realm
name on a different server). So IMO it should definitively be replaced, but
I'm less bothered about what as long as it's obvious what the new example
does.
>
> * Time policy - what about date/time ranges (Mon-Fri, 9am to 17pm,
18-20th
> June, etc..)
Yes, that makes sense.
https://issues.jboss.org/browse/KEYCLOAK-3337
>
> * Evaluate in console - this is a bit awkward to use. I propose we add a
> "view example token" option to clients that can be used to show how a
token
> would look like for a specific user. This would be useful when figuring
out
> protocol mappers, etc.. Then we could piggy back on this feature in the
> evaluation so "real" values from a token could be used when testing
> policies rather than having to manually add all values. This is
especially
> relevant to abac based policies.
Recently, I've changed the evaluation service to re-use the protocol
mappers configured to the client. That means, that the evaluation is now
building a token similar to the real one.
I think now we can easily introduce the UI to "view the example" token. As
well the resulting token with the permissions.
>
> * Role policy - can only select realm level roles. What about client
roles?
https://issues.jboss.org/browse/KEYCLOAK-3338
>
> * Scope - is scope not already a very overused term? Could we call this
> actions, operations or something else?
We have discussed that already. Based on Marek's feedback, I've changed
the tab name to "Authorization Scopes".
I don't like the term Action or Operation. IMO, we should stick with
"Authorization Scopes"/"Scopes".
OK
>
> * Usability - it's easier to find policies and resources on the tabs than
> it is when creating a permission. Maybe we could add a modal panel that
> helps to find resources and policies?
We can have that. But I would also keep current UI to select a policy.
>