Hi Francesco,
On Fri, Sep 8, 2017 at 8:18 AM, Francesco Chicchiriccò <ilgro...@apache.org>
wrote:
>
> Very practical reasons (as said elsewhere I believe): starting with 2.0,
> Entitlements are no more database entities (as they used to be up to 1.2)
> but Java constants.
>
OK thanks for the explanation.
> b) Perhaps the Privileges/Applications could have a few standard
>> attributes, such as "name", "displayName", etc, as well as the JSON
>> description?
>>
>
> Why not? Sure, the one below is just a "bare minimum" proposal.
>
For Roles + Privileges we neeed the following SCIM attributes (value,
display, type, primary). Also for Roles we need creationDate,
lastChangeDate, and possibly others. Is it a possibility to use the same
schema definitions for AnyObjects etc. for the new and improved Role
definition?
I think that modeling Privileges with an optional relationship to
> Applications _might_ cause troubles at JPA level, hence I'd rather go with
> a mandatory relationship.
> If this condition is so problematic for you, we might think to have a
> pre-defined Syncope application (the same way we have a predefined root
> realm, etc.) and you can model "orphan" privileges to be assigned to
> Syncope.
Yep that should work for us, thanks!
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
