On 24/01/2017 20:31, Francesco Chicchiriccò wrote: > On 24 jan 2017 18:29:22 CET, Colm O hEigeartaigh <cohei...@apache.org> ha > scritto: >> Hi Francesco, >> >> Thanks for your detailed reply! It's going to take me some time to wrap >> my >> head around all of the details. :-) > Oh, sorry for this, but these ideas have been ringing in my head for quite > some time... > I have also others, all in the direction of further improving Syncope, and I > am happy to discuss here to clarify, better define, go beyond my direct > experience, etc. > >> Let me just ask an initial question...when you define privilege management >> as " the ability to discover, define and map the rights that users own >> on external resources" - are you referring only to resources in the >> Syncope terminology here - Identity stores like LDAP etc.? >> >> The reason I ask is that our interest is in being able to define >> privileges for external services (say some arbitrary REST service requires a >> given >> entitlement). Is this use-case accommadated by your proposal, or are we >> talking about separate things here? > Interesting point, indeed. > I admit that below I was exactly referring to Syncope's External Resources, > but your sample about REST service is significant. > > Let's suppose we introduce the new concept of Application: what kind of > communication will Syncope establish with it? > Coming to your sample: what would be the use case of managing in Syncope the > privileges available into an external REST service? How would you fetch them? > Supposing you're able to associate them to (groups of) users, wow would you > push such association to the REST service? > > That's why I initially thought to reuse ConnId connectors for this purpose.
After some further thinking on this topic, I have realized that my perspective was simply wrong. I was assuming that Syncope will *provision* privileges to applications in the same way as today it provisions users to resources, but I realize instead that we should reverse the perspective: * 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 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. 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/5e6936a1a9e7fef1f42e7e2261e5fd5dd3ab6aaee669cc82f16284c6@%3Cuser.syncope.apache.org%3E >>> [2] >>> https://lists.apache.org/thread.html/947d7261a242cb729aafb551b28fa9bad6c81c2e02eb6f2ec98b7a0a@1428995050@%3Cuser.syncope.apache.org%3E >>> [3] >>> https://lists.apache.org/thread.html/4662efa8948fc9bba944d8d85ddf902d6c900530ccf78d50df9adb90@1386320489@%3Cuser.syncope.apache.org%3E >>> [4] >>> https://lists.apache.org/thread.html/be01e1d26de4f7b9ce38026364566dc606496d19eba7e008efa227a0@1375945339@%3Cuser.syncope.apache.org%3E >>> [5] >>> https://lists.apache.org/thread.html/e4b5727f8506cdca10cf2a6e4332ed23e9c6f73679fa397bb277abe4@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/
