[DISCUSS] - Privileges in Syncope 2.1.0

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] - Privileges in Syncope 2.1.0

Colm O hEigeartaigh
Hi all,

Following the discussion earlier this year, I'd like to get a better idea
of what is required to support privileges in Syncope 2.1.0:

https://lists.apache.org/thread.html/ba605687b7ed742350834a535b67bda8ab15fe56a4bb75c3dc2b98cd@%3Cdev.syncope.apache.org%3E

To summarise the problem - right now Roles are associated with
Entitlements, which are predefined entities that are only used in terms of
access management within Syncope itself.

However we would like to associate roles with privileges as well (as stated
in the thread above, we can always change the names) to better map standard
concepts of a Role, for example in SCIM.

Should privileges be defined only as Strings or do we need a new type? Do
we need a new REST service etc just for privileges?

The concept of an application was also mentioned in the previous thread (a
role has a privilege for a given application). How will applications be
modeled in Syncope? Will they be optional (if for example we just want to
treat privileges as plain Strings that are interpreted in a third party
application in some way)?

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

ilgrosso
Administrator
On 26/07/2017 18:25, Colm O hEigeartaigh wrote:

> Hi all,
>
> Following the discussion earlier this year, I'd like to get a better idea
> of what is required to support privileges in Syncope 2.1.0:
>
> https://lists.apache.org/thread.html/ba605687b7ed742350834a535b67bda8ab15fe56a4bb75c3dc2b98cd@%3Cdev.syncope.apache.org%3E
>
> To summarise the problem - right now Roles are associated with
> Entitlements, which are predefined entities that are only used in terms of
> access management within Syncope itself.
>
> However we would like to associate roles with privileges as well (as stated
> in the thread above, we can always change the names) to better map standard
> concepts of a Role, for example in SCIM.
>
> Should privileges be defined only as Strings or do we need a new type? Do
> we need a new REST service etc just for privileges?
>
> The concept of an application was also mentioned in the previous thread (a
> role has a privilege for a given application). How will applications be
> modeled in Syncope? Will they be optional (if for example we just want to
> treat privileges as plain Strings that are interpreted in a third party
> application in some way)?

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).

WDYT?
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/

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

Colm O hEigeartaigh
Hi Francesco,

Many thanks for your reply.

On Thu, Jul 27, 2017 at 10:08 AM, Francesco Chicchiriccò <
[hidden email]> 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? 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?

Colm.



>
> WDYT?
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

ilgrosso
Administrator
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ò <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

Colm O hEigeartaigh
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ò <[hidden email]
> 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ò <
>> [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

ilgrosso
Administrator
Hi Colm,
see my replies below.

Regards.

On 07/09/2017 18:20, Colm O hEigeartaigh wrote:
> 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?

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.
This allows to statically reference entitlements in Spring Security
expressions as

https://github.com/apache/syncope/blob/2_0_X/core/logic/src/main/java/org/apache/syncope/core/logic/TaskLogic.java#L120

and Wicket authorization as

https://github.com/apache/syncope/blob/2_0_X/client/console/src/main/java/org/apache/syncope/client/console/topology/TopologyTogglePanel.java#L187

> 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.

> 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.

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.

> On Thu, Aug 17, 2017 at 2:02 PM, Francesco Chicchiriccò <[hidden email]> 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ò <
>>> [hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

Colm O hEigeartaigh
Hi Francesco,

On Fri, Sep 8, 2017 at 8:18 AM, Francesco Chicchiriccò <[hidden email]>
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ò <
>> [hidden email]> 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ò <
>>>> [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

ilgrosso
Administrator
On 08/09/2017 16:33, Colm O hEigeartaigh wrote:

> Hi Francesco,
>
> On Fri, Sep 8, 2017 at 8:18 AM, Francesco Chicchiriccò <[hidden email]>
> 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.

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

> 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.

>> 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!

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/%5BDISCUSS%5D+Dynamic+Realms

?

Regards.

>> On Thu, Aug 17, 2017 at 2:02 PM, Francesco Chicchiriccò <[hidden email]> 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ò <
>>>>> [hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

Colm O hEigeartaigh
On Thu, Sep 14, 2017 at 8:47 AM, Francesco Chicchiriccò <[hidden email]
> 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ò <
>>> [hidden email]> 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ò <
>>>>>> [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Privileges in Syncope 2.1.0

ilgrosso
Administrator
On 14/09/2017 18:36, Colm O hEigeartaigh wrote:
> On Thu, Sep 14, 2017 at 8:47 AM, Francesco Chicchiriccò <[hidden email]> 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.

Wow :-)

>>> 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.

That should be exactly the purpose of the "specification" CLOB attribute
for the Privilege entity in my initial proposal, where any string can be
stored, including some JSON value.

>> 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.

Very nice, indeed.
Regards.

> On Thu, Aug 17, 2017 at 2:02 PM, Francesco Chicchiriccò <
>>>> [hidden email]> 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ò <
>>>>>>> [hidden email]> 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/