[keycloak-user] Additional attributes for an authorization request

[Pedro Igor Silva]

On Thu, Feb 9, 2017 at 2:11 PM, Ori Doolman <Ori.Doolman at amdocs.com> wrote:

> Hi Pedro Igor,
> You wrote:
> You can't pass additional attributes along with an authorization request.
> However, that is something we want to support on future versions.
>
> I have some questions about that:
>
> 1.       Which future version will support that? Any plan for it at the
> moment?
>

Sorry, but can't give you any dates. There are quite a few things in authz
services roadmap, but right now we have some time and resource constraints
that are blocking us to follow a plan/roadmap.


>
> 2.       Until it is supported, what would be the best practice
> recommendation to authorize resources such as account numbers?
>
> For example: The REST API (resource) I want to protect in the resource
> server is  /api/getAccountDetails/{accountNum}. How should I configure
> the policy/permissions/resources/scopes in the PDP and how should I
> utilize the PEP (I'm using Java adapter for JBOSS Fuse)?
>

It seems this one is already supported. I would suggest you to take a look
at the PhotoZ example about how to protect individual resources. There you
will find:

1) How to create resources from your resource server using the Protection
API using the Java AuthZ Client API.
2) How "typed" resources work, where you define permissions to a generic
resources and these permissions are also applied to resources with the same
type.
3) How to configure "policy-enforcer" to handle paths with a pattern in
order to resolve a specific resource instance (e.g.: the account details in
your example). Something like that:

     {
        "name" : "Album Resource",
        "path" : "/album/{id}",
        "methods" : [
          {
            "method": "DELETE",
            "scopes" : ["urn:photoz.com:scopes:album:delete"]
          },
          {
            "method": "GET",
            "scopes" : ["urn:photoz.com:scopes:album:view"]
          }
        ]
      }


>
> Thank you,
> Ori.
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>