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