----- Original Message ----- > From: "Stian Thorgersen" <sthorger(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt;, "keycloak-dev" < keycloak-dev(a)lists.jboss.org&gt; > 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.

> > * 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. >