syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <>
Subject Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Date Wed, 25 Jan 2017 18:20:07 GMT
Hi Francesco,

On Wed, Jan 25, 2017 at 1:59 PM, Francesco Chicchiriccò <
> wrote:

> * Syncope defines applications, privileges and access policies (User U1 is
> allowed to access application A1 with privilege P1)
> * Syncope provides REST endpoint(s) that applications can invoke to check
> if their users own certain privileges

Yes this sounds great, pretty much exactly what I was looking for! :-)

> Essentially, Syncope will provide all means to define and evaluate access
> policies, and I don't see any reason to not adopt the relevant standards in
> this domain, e.g. XACML.

Interesting. So in addition to the REST endpoints that applications can
call to check if users are associated with certain privileges, we could
have a REST Endpoint which acts as a XACML PolicyDecisionPoint, where a
XACML request is evaluated against the set of XACML policies. This would
require modeling the access policies as XACML policies somehow which could
be a bit complex to implement.

We use the XACML RBAC profile for authorization for certain web services. A
web service sends a request to the PDP containing the Subject name + role
(already available from authentication) + the service name (URL or SOAP
service + endpoint String) + desired "action" (HTTP verb for example). The
policies are split into two separate types, a "role" policy which matches
the Subject, and this policy is associated with permission policies (which
associate an "action" with a "resource" so HTTP GET with a URL for
example). It might be interesting to see if the Syncope privilege model
might fall into the same pattern.

I'd suggest maybe that the "evaluation"/XACML part could be considered as a
future extension for now, as I don't think it's needed for the basic
use-case. Our main interest is in using Syncope to authenticate users in an
OpenId Connect IdP, and to then retrieve the privileges of that user (for a
given application) to be inserted into a JWT token. Applications could then
extract the privileges from the received token + apply RBAC etc. So in this
use-case, applications would not communicate with Syncope at all, and hence
wouldn't need to call Syncope for evaluation.


Does it sound better?
> Regards.
> >> On Fri, Jan 20, 2017 at 8:30 AM, Francesco Chicchiriccò<
>> wrote:
> >>
> >>> With "dynamic entitlements", I think you are referring to privilege
> management, e.g. the ability to discover, define and map the rights that
> users own on external resources.
> >>>
> >>> I would not confuse this, however, with Syncope entitlements: starting
> with 2.0, in fact, we now finally have a stable mechanism for which
> entitlements are defined as constants in Java classes (and extensions might
> add their own, as shown by the Camel Provisioning Manager), with positive
> effects on code organization both for Core's Spring Security configuration
> and Admin Console's delegated administration.
> >>>
> >>> I think that privilege management is a great addition to Syncope; here
> are few items coming to my mind:
> >>>
> >>> 1. privileges must be represented as (JPA) entities, have their own
> TO, REST endpoint, Admin Console management, etc. (as all other entities)
> >>> 2. privileges should be defined / discovered in external resource(s):
> resource R1 defines privileges P1, P2, P3; resource R2 defines privileges
> P4,P5; about discovery, ConnId does not provide (yet?) any primitive
> >>> 3. privileges should be grouped somehow and finally assigned to users,
> but depend on each external resource
> >>> 4. privileges are not really for users (in the way Syncope defines
> them) but rather for accounts, e.g. the mapped counterpart of a Syncope
> user onto a given external resource.
> >>>
> >>> I think we could take the chance to add both privilege management and
> multi-account management (see SYNCOPE-957): both features require in fact a
> new concept to be introduced in Syncope: accounts.
> >>>
> >>> Naturally, I don't see any chance to land all above in 2.0
> (considerable changes involved, even for internal storage); it will be 2.1
> at least.
> >>>
> >>> Regards.
> >>>
> >>> [1]
> >>> [2]
> >>> [3]
> >>> [4]
> >>> [5]
> >>>
> >>> On 19/01/2017 17:53, Colm O hEigeartaigh wrote:
> >>>> Hi all,
> >>>>
> >>>> I'd like to discuss the possibility of supporting dynamic
> entitlements in Apache Syncope. The goals being to explore if the Apache
> Syncope community feels that this is a good idea, and if so to try to break
> the various work items down and start creating JIRAs etc.
> >>>>
> >>>> Entitlements in Apache Syncope are currently statically defined and
> are used for internal authorization purposes only. The problem arises when
> you start considering things like integrating SCIM with Syncope, as the
> concepts of roles/entitlements in SCIM do not map naturally to groups in
> Syncope.
> >>>>
> >>>> So it would be great to be able to map roles/entitlements associated
> with users directly to the same concepts in Syncope. I don't know whether
> it might be desirable to have different types of entitlements, e.g. whether
> we want to maintain a separation between "internal" entitlements used
> >>>> for authorization in Syncope, and general entitlements meant for
> external consumption.
> >>>>
> >>>> The task would involve some UI work to be able to create
> entitlements. I'm not sure off-hand if we require REST changes, as we can
> get the entitlements of a User by getting the roles of the user, and then
> querying the entitlements associated with the role etc.
> >>>>
> >>>> Is it possible to associate roles with a group and then have members
> of that group inherit the entitlements?
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Colm.
> --
> Francesco Chicchiriccò
> Tirasa - Open Source Excellence
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail

Colm O hEigeartaigh

Talend Community Coder

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message