Hi Francesco, On Wed, Jan 25, 2017 at 1:59 PM, Francesco Chicchiriccò <ilgro...@apache.org > 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. Colm. Does it sound better? > Regards. > > >> On Fri, Jan 20, 2017 at 8:30 AM, Francesco Chicchiriccò< > ilgro...@apache.org> 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] https://lists.apache.org/thread.html/5e6936a1a9e7fef1f42e7e2 > 261e5fd5dd3ab6aaee669cc82f16284c6@%3Cuser.syncope.apache.org%3E > >>> [2] https://lists.apache.org/thread.html/947d7261a242cb729aafb55 > 1b28fa9bad6c81c2e02eb6f2ec98b7a0a@1428995050@%3Cuser.syncope.apache.org%3E > >>> [3] https://lists.apache.org/thread.html/4662efa8948fc9bba944d8d > 85ddf902d6c900530ccf78d50df9adb90@1386320489@%3Cuser.syncope.apache.org%3E > >>> [4] https://lists.apache.org/thread.html/be01e1d26de4f7b9ce38026 > 364566dc606496d19eba7e008efa227a0@1375945339@%3Cuser.syncope.apache.org%3E > >>> [5] https://lists.apache.org/thread.html/e4b5727f8506cdca10cf2a6 > e4332ed23e9c6f73679fa397bb277abe4@1367333293@%3Cuser.syncope.apache.org%3E > >>> > >>> 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 > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/ > > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
