[keycloak-dev] Feedback on authz services

[Pedro Igor Silva]

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

>