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