On 14/09/2017 18:36, Colm O hEigeartaigh wrote:
On Thu, Sep 14, 2017 at 8:47 AM, Francesco Chicchiriccò <ilgro...@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.
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ò <
ilgro...@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ò <
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/
