Hi Francesco, A few further thoughts on this:
a) Instead of having both entitlements + privileges, would it make sense to only have privileges, where the "entitlements" are privileges on the Syncope application? It would seem less confusing and kind of neat to model everything as a single concept, but maybe there are practical reasons to keep them separate? b) Perhaps the Privileges/Applications could have a few standard attributes, such as "name", "displayName", etc, as well as the JSON description? c) The Application concept is a bit problematic for us, as it requires us to model Applications in Syncope, whereas we are content to have the privileges be interpreted by our applications without having to create the applications in Syncope. For example, a user A might have Role R with privilege P, but we may wish P to apply to a future application for example, something we won't be able to model if is it mandatory to associate a privilege with an application. Colm. On Thu, Aug 17, 2017 at 2:02 PM, Francesco Chicchiriccò <ilgro...@apache.org > wrote: > On 14/08/2017 19:12, Colm O hEigeartaigh wrote: > >> Hi Francesco, >> >> Many thanks for your reply. >> >> On Thu, Jul 27, 2017 at 10:08 AM, Francesco Chicchiriccò < >> ilgro...@apache.org> wrote: >> >> Hi Colm, >>> thanks for bringing back this topic. >>> >>> As said in the original thread mentioned above, I would stay as much >>> general as possible here, because I think we can model for future >>> features. >>> >>> I'd introduce two new entities >>> >>> 1. Application - with name and optional description >>> 2. Privilege - with name and optional specification >>> (I see this specification as a CLOB where one could put some descriptive >>> JSON to provide operational information about this privilege: for >>> example, >>> it could be { "method": "POST", "url": "/a/b/c" } and then 3rd party apps >>> can interpret that as needed) >>> >>> where an Application can have zero or more Privileges attached; I don't >>> think it makes much sense to have Privileges shared by different >>> Applications, hence I would model a @OneToMany relationship. >>> >>> Then, Roles can be associated to zero or more Privileges. >>> >>> I think a single new REST /applications endpoint should be enough, >>> working >>> with ApplicationTO (having a List<PrivilegeTO> privileges field). >>> >> I want to be sure that I fully understand what you are proposing here. >> >> RoleTOs will be associated with: >> a) Set<String> entitlements (as current) >> b) Set<PrivilegeTO> privileges >> >> ApplicationTOs will be associated with: >> a) Set<PrivilegeTO> privileges >> >> If a user U is in role R then A has privilege P on application A. Is my >> understanding correct so far? >> > > If U is in role R, then U has privilege P on application A (if P belongs > to A). > > Will privileges exist independently of >> applications? Or if say we add a privilege P to role R, will the logic >> check that an application exists with that privilege P? >> > > I don't think it makes sense to have privileges separated from > applications. > But naturally, any helping feature implemented at REST / Logic layer is > welcome. > > > Regards. > > -- > 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