On 08/09/2017 16:33, Colm O hEigeartaigh wrote:
Hi Francesco,
On Fri, Sep 8, 2017 at 8:18 AM, Francesco Chicchiriccò <ilgro...@apache.org>
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ò <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/
