<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 July 2016 at 14:41, Pedro Igor Silva <span dir="ltr"><<a href="mailto:psilva@redhat.com" target="_blank">psilva@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Stian Thorgersen" <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>><br>
> To: "Pedro Igor Silva" <<a href="mailto:psilva@redhat.com">psilva@redhat.com</a>>, "keycloak-dev" <<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>><br>
> Sent: Tuesday, July 19, 2016 5:02:48 AM<br>
> Subject: Feedback on authz services<br>
><br>
> Things we could add:<br>
> ----------------------------<br>
><br>
> * Add policy enforcement support to Keycloak Proxy<br>
><br>
> * Node.js adapter<br>
<br>
</span><a href="https://issues.jboss.org/browse/KEYCLOAK-3333" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3333</a><br>
<a href="https://issues.jboss.org/browse/KEYCLOAK-3334" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3334</a><br>
<span class=""><br>
><br>
><br>
> Comments:<br>
> ---------------<br>
><br>
> * Docs - added a few comments (<br>
> <a href="https://www.gitbook.com/book/keycloak/authorization-services-guide/discussions" rel="noreferrer" target="_blank">https://www.gitbook.com/book/keycloak/authorization-services-guide/discussions</a><br>
> )<br>
<br>
</span>Will look at that.<br>
<span class=""><br>
><br>
> * JS Policy - I found it hard to figure out how to write these, especially<br>
> since the docs are showing Java interfaces<br>
<br>
</span>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.<br>
<br>
But I understand your point, I'm going to improve that doc and make it more JS-friendly.<br>
<span class=""><br>
><br>
> * Attribute based policy - We don't seem to have a simple attribute based<br>
> policy, should we not have this?<br>
<br>
</span>Yes, that makes sense. <a href="https://issues.jboss.org/browse/KEYCLOAK-3335" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3335</a><br>
<span class=""><br>
><br>
> * Default policy (only from realm) - This default makes no sense. I'd<br>
> suggest removing or replacing with something that's more obvious like<br>
> "require user to have an email set"<br>
<br>
</span>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.<br>
<br>
The motivations behind that policy are:<br>
<br>
* Show that you can use rule-based policies<br>
* Show that we have an API that you can use to build these policies<br>
* Show that you can perform decisions based on attributes from both environment and identity (ABAC)<br>
<br>
Although redundant, that policy is a good start point to understand some capabilities we provide.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> * Time policy - what about date/time ranges (Mon-Fri, 9am to 17pm, 18-20th<br>
> June, etc..)<br>
<br>
</span>Yes, that makes sense.<br>
<br>
<a href="https://issues.jboss.org/browse/KEYCLOAK-3337" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3337</a><br>
<span class=""><br>
><br>
> * Evaluate in console - this is a bit awkward to use. I propose we add a<br>
> "view example token" option to clients that can be used to show how a token<br>
> would look like for a specific user. This would be useful when figuring out<br>
> protocol mappers, etc.. Then we could piggy back on this feature in the<br>
> evaluation so "real" values from a token could be used when testing<br>
> policies rather than having to manually add all values. This is especially<br>
> relevant to abac based policies.<br>
<br>
</span>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.<br>
<br>
I think now we can easily introduce the UI to "view the example" token. As well the resulting token with the permissions.<br>
<span class=""><br>
><br>
> * Role policy - can only select realm level roles. What about client roles?<br>
<br>
</span><a href="https://issues.jboss.org/browse/KEYCLOAK-3338" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3338</a><br>
<span class=""><br>
><br>
> * Scope - is scope not already a very overused term? Could we call this<br>
> actions, operations or something else?<br>
<br>
</span>We have discussed that already. Based on Marek's feedback, I've changed the tab name to "Authorization Scopes".<br>
<br>
I don't like the term Action or Operation. IMO, we should stick with "Authorization Scopes"/"Scopes".<br></blockquote><div><br></div><div>OK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> * Usability - it's easier to find policies and resources on the tabs than<br>
> it is when creating a permission. Maybe we could add a modal panel that<br>
> helps to find resources and policies?<br>
<br>
</span>We can have that. But I would also keep current UI to select a policy.<br>
<br>
><br>
</blockquote></div><br></div></div>