[keycloak-user] Policy-API - How to Set a User Policy

stefan.wachter stefan.wachter at bosch-si.com
Wed Jul 18 12:13:38 EDT 2018


https://issues.jboss.org/browse/KEYCLOAK-7885

Best regards,

*Stefan Wachter
INST-ICM/BSV-BS*

Tel.  +49(711)811-58477

*Be**QIK
*

Am 18.07.2018 um 16:14 schrieb Pedro Igor Silva:
> I see. Well, I think we can include this as it just adds support for 
> another policy type. Another JIRA, please ? :)
>
> On Wed, Jul 18, 2018 at 10:05 AM, stefan.wachter 
> <stefan.wachter at bosch-si.com <mailto:stefan.wachter at bosch-si.com>> wrote:
>
>     Ok. I understand. However, I would like to set the policy that
>     allows a certain user to access a resource upfront. For example
>     when a resource owner decides to share a resource with someone by
>     sending an email she wants to set the necessary policy at the same
>     time (and not later on in a separate approval step). This is what
>     the User Management UI already offers. But I would like to
>     implement that functionality by API calls.
>
>     Best regards,
>
>     *Stefan Wachter
>     INST-ICM/BSV-BS*
>
>     Tel.  +49(711)811-58477
>
>     *Be**QIK
>     *
>
>     Am 18.07.2018 um 14:20 schrieb Pedro Igor Silva:
>>
>>
>>     On Wed, Jul 18, 2018 at 5:43 AM, stefan.wachter
>>     <stefan.wachter at bosch-si.com
>>     <mailto:stefan.wachter at bosch-si.com>> wrote:
>>
>>         Hi,
>>
>>         how can one set a user policy, (i.e. a set of users) to a
>>         user managed
>>         resource? Looking at the class
>>         org.keycloak.representations.idm.authorization.UmaPermissionRepresentation
>>
>>         I do not see a field that could be used for specifiying a set
>>         of user ids.
>>
>>
>>     For users, the idea is that you would probably want to follow UMA
>>     flow. The idea behind this endpoint is allow resource servers to
>>     define additional permissions (in addition to users as provided
>>     by UMA flow) and still allow users to revoke them.
>>
>>
>>
>>         public class UmaPermissionRepresentationextends
>>         AbstractPolicyRepresentation {
>>
>>              private Stringid;
>>              private Stringdescription;
>>              private Set<String>roles;
>>              private Set<String>groups;
>>              private Set<String>clients;
>>              private Stringcondition;
>>         ...
>>         }
>>
>>         public class AbstractPolicyRepresentation {
>>
>>              private Stringid;
>>              private Stringname;
>>              private Stringdescription;
>>              private Stringtype;
>>              private Set<String>policies;
>>              private Set<String>resources;
>>              private Set<String>scopes;
>>              private Logiclogic = Logic.POSITIVE;
>>              private DecisionStrategydecisionStrategy =
>>         DecisionStrategy.UNANIMOUS;
>>              private Stringowner;
>>         ...
>>
>>         }
>>
>>         BTW: Why does the derived UmaPermissionRepresentation class
>>         have an id
>>         and description field of its own? I think these fields are
>>         inherited
>>         from its base class AbstractPolicyRepresentation.
>>
>>
>>     Good point. Need to refactor this.
>>
>>
>>         -- 
>>
>>         Best regards,
>>
>>         *Stefan Wachter
>>         INST-ICM/BSV-BS*
>>
>>         Tel.  +49(711)811-58477
>>
>>         *Be**QIK
>>         *
>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>
>>
>
>



More information about the keycloak-user mailing list