Mailing-List: contact dev-help@syncope.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@syncope.apache.org
MIME-Version: 1.0
Reply-To: coheigea@apache.org
In-Reply-To: <c3449876-a9b5-d5a6-2f9b-4c922757d15c@apache.org>
References: <CAB8XdGAdkXFhFxsc2wvmCxYUPhRgWPgwrf-Q+tFpoQWq286LZw@mail.gmail.com>
 <7557b855-adfb-229c-bc15-a4e22351b726@apache.org> <CAB8XdGCqGh=COLT0sD635T5i8u3q8AQWMvY2bA9HyPoOeGoSww@mail.gmail.com>
 <3e11e3d5-ad58-bfd2-1446-ea7990e28f8c@apache.org> <CAB8XdGBFupJU2q2ikFBwDX5J7KN67nFjJC4aM1A8QrQeSqvHKA@mail.gmail.com>
 <c3449876-a9b5-d5a6-2f9b-4c922757d15c@apache.org>
From: Colm O hEigeartaigh <coheigea@apache.org>
Date: Fri, 8 Sep 2017 15:33:37 +0100
Message-ID: <CAB8XdGBeFetOY_60Wzwo+Brzu50RP35tWiHrDitYMMwydjSctQ@mail.gmail.com>
Subject: Re: [DISCUSS] - Privileges in Syncope 2.1.0
To: "dev@syncope.apache.org" <dev@syncope.apache.org>
Content-Type: multipart/alternative; boundary="94eb2c11acfe754dba0558ae761d"
archived-at: Fri, 08 Sep 2017 14:33:43 -0000

--94eb2c11acfe754dba0558ae761d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Francesco,

On Fri, Sep 8, 2017 at 8:18 AM, Francesco Chicchiricc=C3=B2 <ilgrosso@apach=
e.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 wit=
h
> 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=C3=B2 <
>> ilgrosso@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=C3=B2 <
>>>> ilgrosso@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 m=
y
>>>> understanding correct so far?
>>>>
>>>> If U is in role R, then U has privilege P on application A (if P belon=
gs
>>> 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=C3=B2
>
> 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/
>
>


--=20
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

--94eb2c11acfe754dba0558ae761d--