[DISCUSS] - Privileges in Syncope 2.1.0

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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/

Loading...