----- Original Message -----
> From: "Stian Thorgersen" <sthorger@redhat.com>
> To: "Pedro Igor Silva" <psilva@redhat.com>, "keycloak-dev" <keycloak-dev@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/discussions
> )
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.
>
> * 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".
>
> * 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.
>