syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: [DISCUSS] - Privileges in Syncope 2.1.0
Date Thu, 14 Sep 2017 16:36:30 GMT
On Thu, Sep 14, 2017 at 8:47 AM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:

>
> That's fine.
> (SCIM? Are you working on something that might be useful for SYNCOPE-152?)
>

Yes, hopefully I will have some news on this soon.


>
> Is it a possibility to use the same schema definitions for AnyObjects etc.
>> for the new and improved Role
>> definition?
>>
>
> Hummm, I don't think it is a good idea: so far Schemas are only for Users,
> Groups and Any Objects, e.g. for entities that are subject to provisioning.
>

OK that's fine. So long as there is some way to specify arbitrary
attributes I suppose.


>
> Cool: are you going to take care of opening an issue for this topic,
> possibly supported by a more extensive wiki page as
>
> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCU
> SS%5D+Dynamic+Realms



Yes, makes sense. I need to get a few things clearer in my mind, and then
I'll start this process.

Colm.

>
>
> ?
>
> Regards.
>
>
> On Thu, Aug 17, 2017 at 2:02 PM, Francesco Chicchiriccò <
>>> 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ò <
>>>>>> 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
>>>>>> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message