syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <>
Subject Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Date Thu, 26 Jan 2017 08:06:31 GMT
On 25/01/2017 19:20, Colm O hEigeartaigh wrote:
> Hi Francesco,
> On Wed, Jan 25, 2017 at 1:59 PM, Francesco Chicchiriccò <>
>> * 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! :-)

Good to hear that.

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

I agree that XACML policy definition / evaluation could be involved enough to send it to later

About the definition of the new Application and Privilege (and their relationship with existing
User and Group, for example), however, these will still require new JPA entities to be defined
for internal storage, new TO and ultimately something for Admin UI management.

One could think to model all this in an extension (e.g. sources under ext/ in our codebase,
as the Camel Provisioning Manager), which could be set for immediate availability in 2.0.X,
with option for direct inclusion in the 2.1 source tree (e.g. under common/ client/ and core/).

Finally, I want to let you know that I am quite advanced in building a prototype - which could
be likely delivered in a month or two - that introduces Digest Authentication and JWT token
management in Syncope 2.0.X (you might want to ask Sergey about my stressful questions around
these points in CXF...).

Francesco Chicchiriccò

Tirasa - Open Source Excellence

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail

View raw message