[keycloak-dev] Feedback on authz services

[Stian Thorgersen]

On 19 July 2016 at 14:41, Pedro Igor Silva <psilva at redhat.com> wrote:

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

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.
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160719/bb5e41d2/attachment.html