You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2017/01/19 16:53:46 UTC
[DISCUSS] - Support dynamic entitlements in Apache Syncope
Hi all,
I'd like to discuss the possibility of supporting dynamic entitlements in
Apache Syncope. The goals being to explore if the Apache Syncope community
feels that this is a good idea, and if so to try to break the various work
items down and start creating JIRAs etc.
Entitlements in Apache Syncope are currently statically defined and are
used for internal authorization purposes only. The problem arises when you
start considering things like integrating SCIM with Syncope, as the
concepts of roles/entitlements in SCIM do not map naturally to groups in
Syncope.
So it would be great to be able to map roles/entitlements associated with
users directly to the same concepts in Syncope. I don't know whether it
might be desirable to have different types of entitlements, e.g. whether we
want to maintain a separation between "internal" entitlements used for
authorization in Syncope, and general entitlements meant for external
consumption.
The task would involve some UI work to be able to create entitlements. I'm
not sure off-hand if we require REST changes, as we can get the
entitlements of a User by getting the roles of the user, and then querying
the entitlements associated with the role etc.
Is it possible to associate roles with a group and then have members of
that group inherit the entitlements?
WDYT?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 01/02/2017 22:13, Adrian Gonzalez wrote:
> Hello Colm and Francesco,
>
>> Summarizing: while Roles currently have only Entitlements associated, in the future we might also associate Privileges (which in turn are related to Applications) to them. As a result, user U with role R will own both
>> Entitlements and Privileges.> If "privilege" is not suitable as name, let's then rename the existing
>> Entitlements to something else and use the word "entitlement" to model the new concept instead.
> Would it make sense to have an association from Group to Roles also ?
>
>
> If yes, we would end with :
> Role
>
> 0..n entitlements
> 0..n privileges
> Group
> 0..n roles
> 0..n users
> User
> 0..n roles
I don't see the point in associating Groups to Roles: the former are
both for Users and Any Objects, the latter only for Users.
Moreover, you can always define dynamic Group memberships based on Role
assignment and vice-versa [1][2], e.g. User U is dynamically assigned
role R because he is member of Group G or U is dynamically member of G
because he has R assigned.
Regards.
[1]
https://syncope.apache.org/docs/reference-guide.html#memberships-relationships
[2] https://syncope.apache.org/docs/reference-guide.html#roles
--
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/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Adrian Gonzalez <ad...@yahoo.fr.INVALID>.
Hello Colm and Francesco,
> Summarizing: while Roles currently have only Entitlements associated, in
> the future we might also associate Privileges (which in turn are related
> to Applications) to them. As a result, user U with role R will own both
> Entitlements and Privileges.> If "privilege" is not suitable as name, let's then rename the existing
> Entitlements to something else and use the word "entitlement" to model
> the new concept instead.
Would it make sense to have an association from Group to Roles also ?
If yes, we would end with :
Role
0..n entitlements
0..n privileges
Group
0..n roles
0..n users
User
0..n roles
Regards,
Adrian
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 02/02/2017 17:54, Colm O hEigeartaigh wrote:
> Hi Francesco,
>
> On Wed, Feb 1, 2017 at 10:54 AM, Francesco Chicchiricc� <il...@apache.org> wrote:
>
>> I agree that the existing Roles in Syncope are fine to map that concept;
>> the problem I see to assimilate the existing Entitlements with the new
>> entities being discussed so far in this thread, e.g. Privileges and
>> Applications.
>>
>> Entitlements are a pre-defined set of strings (which can also be extended,
>> as we see in the Camel Provisioning Manager), specifically targeted to
>> implement delegated administration, e.g. only for internal purpose.
>>
>> Privileges could be instead used to model the rights on a given
>> Application; please note that the former might depend on the latter, e.g.
>> "POST on /a/b/c" but also "Administer printers".
>>
>> Summarizing: while Roles currently have only Entitlements associated, in
>> the future we might also associate Privileges (which in turn are related to
>> Applications) to them. As a result, user U with role R will own both
>> Entitlements and Privileges.
>>
>> If "privilege" is not suitable as name, let's then rename the existing
>> Entitlements to something else and use the word "entitlement" to model the
>> new concept instead.
>>
> OK this all sounds fine to me. Hopefully we are nearing agreement :-)
>
> <SNIP from other email>
>> I don't see the point in associating Groups to Roles: the former are both
>> for Users and Any Objects, the latter only for Users.
>>
>> Moreover, you can always define dynamic Group memberships based on Role
>> assignment and vice-versa [1][2], e.g. User U is dynamically assigned role
>> R because he is member of Group G or U is dynamically member of G because
>> he has R assigned.
> I agree that dynamic role association due to group membership models the
> scenario of "every user in Group X should have role Y". There's probably
> nothing too objectionable about supporting being able to statically
> configure it though. Are there potential performance problems with dynamic
> membership I wonder if you're dealing with large amounts of entities?
I don't think so: dynamic memberships are actually not calculated on the
fly but rather stored and updated upon user create / update.
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/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
On Wed, Feb 1, 2017 at 10:54 AM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:
> I agree that the existing Roles in Syncope are fine to map that concept;
> the problem I see to assimilate the existing Entitlements with the new
> entities being discussed so far in this thread, e.g. Privileges and
> Applications.
>
> Entitlements are a pre-defined set of strings (which can also be extended,
> as we see in the Camel Provisioning Manager), specifically targeted to
> implement delegated administration, e.g. only for internal purpose.
>
> Privileges could be instead used to model the rights on a given
> Application; please note that the former might depend on the latter, e.g.
> "POST on /a/b/c" but also "Administer printers".
>
> Summarizing: while Roles currently have only Entitlements associated, in
> the future we might also associate Privileges (which in turn are related to
> Applications) to them. As a result, user U with role R will own both
> Entitlements and Privileges.
>
> If "privilege" is not suitable as name, let's then rename the existing
> Entitlements to something else and use the word "entitlement" to model the
> new concept instead.
>
OK this all sounds fine to me. Hopefully we are nearing agreement :-)
<SNIP from other email>
I don't see the point in associating Groups to Roles: the former are both
> for Users and Any Objects, the latter only for Users.
>
> Moreover, you can always define dynamic Group memberships based on Role
> assignment and vice-versa [1][2], e.g. User U is dynamically assigned role
> R because he is member of Group G or U is dynamically member of G because
> he has R assigned.
I agree that dynamic role association due to group membership models the
scenario of "every user in Group X should have role Y". There's probably
nothing too objectionable about supporting being able to statically
configure it though. Are there potential performance problems with dynamic
membership I wonder if you're dealing with large amounts of entities?
Colm.
>
> 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
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 31/01/2017 18:03, Colm O hEigeartaigh wrote:
> Hi Francesco,
>
> On Thu, Jan 26, 2017 at 8:06 AM, Francesco Chicchiricc� <il...@apache.org> wrote:
>
>> About the definition of the new Application and Privilege (and their
>> relationship with existing User and Group, for example), however, these
>> will still require new JPA entities to be defined for internal storage, new
>> TO and ultimately something for Admin UI management.
> I'm wondering how (or if) the concept of roles fits into this scenario of
> Applications and Privileges? The problem for us is that the existing
> entitlements/roles concepts in Syncope seems to map perfectly to that of
> SCIM, along the lines of:
>
> https://groups.google.com/forum/#!msg/cloud-directory/fs6szjVrBBA/tt3t0PZg0UEJ
>
> It's not really clear to me why we can't re-use the existing concepts to
> model entitlements/roles external to Syncope? Will there be a way to group
> privileges similar to the way that roles group entitlements?
I have read with interest the link above.
I agree that the existing Roles in Syncope are fine to map that concept;
the problem I see to assimilate the existing Entitlements with the new
entities being discussed so far in this thread, e.g. Privileges and
Applications.
Entitlements are a pre-defined set of strings (which can also be
extended, as we see in the Camel Provisioning Manager), specifically
targeted to implement delegated administration, e.g. only for internal
purpose.
Privileges could be instead used to model the rights on a given
Application; please note that the former might depend on the latter,
e.g. "POST on /a/b/c" but also "Administer printers".
Summarizing: while Roles currently have only Entitlements associated, in
the future we might also associate Privileges (which in turn are related
to Applications) to them. As a result, user U with role R will own both
Entitlements and Privileges.
If "privilege" is not suitable as name, let's then rename the existing
Entitlements to something else and use the word "entitlement" to model
the new concept instead.
>> Finally, I want to let you know that I am quite advanced in building a
>> prototype - which could be likely delivered in a month or two - that
>> introduces Digest Authentication and JWT token management in Syncope 2.0.X
>> (you might want to ask Sergey about my stressful questions around these
>> points in CXF...).
> Cool, are you referring to being able to perform authentication in Syncope
> with a signed JWT token here or something else?
The idea is that the first invocation of a specific REST endpoint will
be used only for authentication (which will be set by default to Digest
Authentication, but could be any other mechanism including SAML 2.0, for
example); such call will return a signed JWT token, which could be used
for subsequent calls. Refresh and ban / blacklist mechanism will be also
provided.
I have found such approach being reported as REST best practice.
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/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
On Thu, Jan 26, 2017 at 8:06 AM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:
>
> About the definition of the new Application and Privilege (and their
> relationship with existing User and Group, for example), however, these
> will still require new JPA entities to be defined for internal storage, new
> TO and ultimately something for Admin UI management.
>
I'm wondering how (or if) the concept of roles fits into this scenario of
Applications and Privileges? The problem for us is that the existing
entitlements/roles concepts in Syncope seems to map perfectly to that of
SCIM, along the lines of:
https://groups.google.com/forum/#!msg/cloud-directory/
fs6szjVrBBA/tt3t0PZg0UEJ
It's not really clear to me why we can't re-use the existing concepts to
model entitlements/roles external to Syncope? Will there be a way to group
privileges similar to the way that roles group entitlements?
>
> Finally, I want to let you know that I am quite advanced in building a
> prototype - which could be likely delivered in a month or two - that
> introduces Digest Authentication and JWT token management in Syncope 2.0.X
> (you might want to ask Sergey about my stressful questions around these
> points in CXF...).
>
Cool, are you referring to being able to perform authentication in Syncope
with a signed JWT token here or something else?
Thanks,
Colm.
>
> 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
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 25/01/2017 19:20, Colm O hEigeartaigh wrote:
> Hi Francesco,
>
> On Wed, Jan 25, 2017 at 1:59 PM, Francesco Chicchiriccò <il...@apache.org> wrote:
>
>> * Syncope defines applications, privileges and access policies (User U1 is
>> allowed to access application A1 with privilege P1)
>> * Syncope provides REST endpoint(s) that applications can invoke to check
>> if their users own certain privileges
> Yes this sounds great, pretty much exactly what I was looking for! :-)
Good to hear that.
>> Essentially, Syncope will provide all means to define and evaluate access
>> policies, and I don't see any reason to not adopt the relevant standards in
>> this domain, e.g. XACML.
> Interesting. So in addition to the REST endpoints that applications can
> call to check if users are associated with certain privileges, we could
> have a REST Endpoint which acts as a XACML PolicyDecisionPoint, where a
> XACML request is evaluated against the set of XACML policies. This would
> require modeling the access policies as XACML policies somehow which could
> be a bit complex to implement.
>
> We use the XACML RBAC profile for authorization for certain web services. A
> web service sends a request to the PDP containing the Subject name + role
> (already available from authentication) + the service name (URL or SOAP
> service + endpoint String) + desired "action" (HTTP verb for example). The
> policies are split into two separate types, a "role" policy which matches
> the Subject, and this policy is associated with permission policies (which
> associate an "action" with a "resource" so HTTP GET with a URL for
> example). It might be interesting to see if the Syncope privilege model
> might fall into the same pattern.
>
> I'd suggest maybe that the "evaluation"/XACML part could be considered as a
> future extension for now, as I don't think it's needed for the basic
> use-case. Our main interest is in using Syncope to authenticate users in an
> OpenId Connect IdP, and to then retrieve the privileges of that user (for a
> given application) to be inserted into a JWT token. Applications could then
> extract the privileges from the received token + apply RBAC etc. So in this
> use-case, applications would not communicate with Syncope at all, and hence
> wouldn't need to call Syncope for evaluation.
I agree that XACML policy definition / evaluation could be involved enough to send it to later implementation.
About the definition of the new Application and Privilege (and their relationship with existing User and Group, for example), however, these will still require new JPA entities to be defined for internal storage, new TO and ultimately something for Admin UI management.
One could think to model all this in an extension (e.g. sources under ext/ in our codebase, as the Camel Provisioning Manager), which could be set for immediate availability in 2.0.X, with option for direct inclusion in the 2.1 source tree (e.g. under common/ client/ and core/).
Finally, I want to let you know that I am quite advanced in building a prototype - which could be likely delivered in a month or two - that introduces Digest Authentication and JWT token management in Syncope 2.0.X (you might want to ask Sergey about my stressful questions around these points in CXF...).
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/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
On Wed, Jan 25, 2017 at 1:59 PM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:
>
> * Syncope defines applications, privileges and access policies (User U1 is
> allowed to access application A1 with privilege P1)
> * Syncope provides REST endpoint(s) that applications can invoke to check
> if their users own certain privileges
>
Yes this sounds great, pretty much exactly what I was looking for! :-)
> Essentially, Syncope will provide all means to define and evaluate access
> policies, and I don't see any reason to not adopt the relevant standards in
> this domain, e.g. XACML.
>
Interesting. So in addition to the REST endpoints that applications can
call to check if users are associated with certain privileges, we could
have a REST Endpoint which acts as a XACML PolicyDecisionPoint, where a
XACML request is evaluated against the set of XACML policies. This would
require modeling the access policies as XACML policies somehow which could
be a bit complex to implement.
We use the XACML RBAC profile for authorization for certain web services. A
web service sends a request to the PDP containing the Subject name + role
(already available from authentication) + the service name (URL or SOAP
service + endpoint String) + desired "action" (HTTP verb for example). The
policies are split into two separate types, a "role" policy which matches
the Subject, and this policy is associated with permission policies (which
associate an "action" with a "resource" so HTTP GET with a URL for
example). It might be interesting to see if the Syncope privilege model
might fall into the same pattern.
I'd suggest maybe that the "evaluation"/XACML part could be considered as a
future extension for now, as I don't think it's needed for the basic
use-case. Our main interest is in using Syncope to authenticate users in an
OpenId Connect IdP, and to then retrieve the privileges of that user (for a
given application) to be inserted into a JWT token. Applications could then
extract the privileges from the received token + apply RBAC etc. So in this
use-case, applications would not communicate with Syncope at all, and hence
wouldn't need to call Syncope for evaluation.
Colm.
Does it sound better?
> Regards.
>
> >> On Fri, Jan 20, 2017 at 8:30 AM, Francesco Chicchiriccò<
> ilgrosso@apache.org> wrote:
> >>
> >>> With "dynamic entitlements", I think you are referring to privilege
> management, e.g. the ability to discover, define and map the rights that
> users own on external resources.
> >>>
> >>> I would not confuse this, however, with Syncope entitlements: starting
> with 2.0, in fact, we now finally have a stable mechanism for which
> entitlements are defined as constants in Java classes (and extensions might
> add their own, as shown by the Camel Provisioning Manager), with positive
> effects on code organization both for Core's Spring Security configuration
> and Admin Console's delegated administration.
> >>>
> >>> I think that privilege management is a great addition to Syncope; here
> are few items coming to my mind:
> >>>
> >>> 1. privileges must be represented as (JPA) entities, have their own
> TO, REST endpoint, Admin Console management, etc. (as all other entities)
> >>> 2. privileges should be defined / discovered in external resource(s):
> resource R1 defines privileges P1, P2, P3; resource R2 defines privileges
> P4,P5; about discovery, ConnId does not provide (yet?) any primitive
> >>> 3. privileges should be grouped somehow and finally assigned to users,
> but depend on each external resource
> >>> 4. privileges are not really for users (in the way Syncope defines
> them) but rather for accounts, e.g. the mapped counterpart of a Syncope
> user onto a given external resource.
> >>>
> >>> I think we could take the chance to add both privilege management and
> multi-account management (see SYNCOPE-957): both features require in fact a
> new concept to be introduced in Syncope: accounts.
> >>>
> >>> Naturally, I don't see any chance to land all above in 2.0
> (considerable changes involved, even for internal storage); it will be 2.1
> at least.
> >>>
> >>> Regards.
> >>>
> >>> [1] https://lists.apache.org/thread.html/5e6936a1a9e7fef1f42e7e2
> 261e5fd5dd3ab6aaee669cc82f16284c6@%3Cuser.syncope.apache.org%3E
> >>> [2] https://lists.apache.org/thread.html/947d7261a242cb729aafb55
> 1b28fa9bad6c81c2e02eb6f2ec98b7a0a@1428995050@%3Cuser.syncope.apache.org%3E
> >>> [3] https://lists.apache.org/thread.html/4662efa8948fc9bba944d8d
> 85ddf902d6c900530ccf78d50df9adb90@1386320489@%3Cuser.syncope.apache.org%3E
> >>> [4] https://lists.apache.org/thread.html/be01e1d26de4f7b9ce38026
> 364566dc606496d19eba7e008efa227a0@1375945339@%3Cuser.syncope.apache.org%3E
> >>> [5] https://lists.apache.org/thread.html/e4b5727f8506cdca10cf2a6
> e4332ed23e9c6f73679fa397bb277abe4@1367333293@%3Cuser.syncope.apache.org%3E
> >>>
> >>> On 19/01/2017 17:53, Colm O hEigeartaigh wrote:
> >>>> Hi all,
> >>>>
> >>>> I'd like to discuss the possibility of supporting dynamic
> entitlements in Apache Syncope. The goals being to explore if the Apache
> Syncope community feels that this is a good idea, and if so to try to break
> the various work items down and start creating JIRAs etc.
> >>>>
> >>>> Entitlements in Apache Syncope are currently statically defined and
> are used for internal authorization purposes only. The problem arises when
> you start considering things like integrating SCIM with Syncope, as the
> concepts of roles/entitlements in SCIM do not map naturally to groups in
> Syncope.
> >>>>
> >>>> So it would be great to be able to map roles/entitlements associated
> with users directly to the same concepts in Syncope. I don't know whether
> it might be desirable to have different types of entitlements, e.g. whether
> we want to maintain a separation between "internal" entitlements used
> >>>> for authorization in Syncope, and general entitlements meant for
> external consumption.
> >>>>
> >>>> The task would involve some UI work to be able to create
> entitlements. I'm not sure off-hand if we require REST changes, as we can
> get the entitlements of a User by getting the roles of the user, and then
> querying the entitlements associated with the role etc.
> >>>>
> >>>> Is it possible to associate roles with a group and then have members
> of that group inherit the entitlements?
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Colm.
> --
> 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
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24/01/2017 20:31, Francesco Chicchiriccò wrote:
> On 24 jan 2017 18:29:22 CET, Colm O hEigeartaigh <co...@apache.org> ha scritto:
>> Hi Francesco,
>>
>> Thanks for your detailed reply! It's going to take me some time to wrap
>> my
>> head around all of the details. :-)
> Oh, sorry for this, but these ideas have been ringing in my head for quite some time...
> I have also others, all in the direction of further improving Syncope, and I am happy to discuss here to clarify, better define, go beyond my direct experience, etc.
>
>> Let me just ask an initial question...when you define privilege management
>> as " the ability to discover, define and map the rights that users own
>> on external resources" - are you referring only to resources in the
>> Syncope terminology here - Identity stores like LDAP etc.?
>>
>> The reason I ask is that our interest is in being able to define
>> privileges for external services (say some arbitrary REST service requires a given
>> entitlement). Is this use-case accommadated by your proposal, or are we
>> talking about separate things here?
> Interesting point, indeed.
> I admit that below I was exactly referring to Syncope's External Resources, but your sample about REST service is significant.
>
> Let's suppose we introduce the new concept of Application: what kind of communication will Syncope establish with it?
> Coming to your sample: what would be the use case of managing in Syncope the privileges available into an external REST service? How would you fetch them? Supposing you're able to associate them to (groups of) users, wow would you push such association to the REST service?
>
> That's why I initially thought to reuse ConnId connectors for this purpose.
After some further thinking on this topic, I have realized that my perspective was simply wrong.
I was assuming that Syncope will *provision* privileges to applications in the same way as today it provisions users to resources, but I realize instead that we should reverse the perspective:
* Syncope defines applications, privileges and access policies (User U1 is allowed to access application A1 with privilege P1)
* Syncope provides REST endpoint(s) that applications can invoke to check if their users own certain privileges
Essentially, Syncope will provide all means to define and evaluate access policies, and I don't see any reason to not adopt the relevant standards in this domain, e.g. XACML.
Does it sound better?
Regards.
>> On Fri, Jan 20, 2017 at 8:30 AM, Francesco Chicchiriccò<il...@apache.org> wrote:
>>
>>> With "dynamic entitlements", I think you are referring to privilege management, e.g. the ability to discover, define and map the rights that users own on external resources.
>>>
>>> I would not confuse this, however, with Syncope entitlements: starting with 2.0, in fact, we now finally have a stable mechanism for which entitlements are defined as constants in Java classes (and extensions might add their own, as shown by the Camel Provisioning Manager), with positive effects on code organization both for Core's Spring Security configuration and Admin Console's delegated administration.
>>>
>>> I think that privilege management is a great addition to Syncope; here are few items coming to my mind:
>>>
>>> 1. privileges must be represented as (JPA) entities, have their own TO, REST endpoint, Admin Console management, etc. (as all other entities)
>>> 2. privileges should be defined / discovered in external resource(s): resource R1 defines privileges P1, P2, P3; resource R2 defines privileges P4,P5; about discovery, ConnId does not provide (yet?) any primitive
>>> 3. privileges should be grouped somehow and finally assigned to users, but depend on each external resource
>>> 4. privileges are not really for users (in the way Syncope defines them) but rather for accounts, e.g. the mapped counterpart of a Syncope user onto a given external resource.
>>>
>>> I think we could take the chance to add both privilege management and multi-account management (see SYNCOPE-957): both features require in fact a new concept to be introduced in Syncope: accounts.
>>>
>>> Naturally, I don't see any chance to land all above in 2.0 (considerable changes involved, even for internal storage); it will be 2.1 at least.
>>>
>>> Regards.
>>>
>>> [1] https://lists.apache.org/thread.html/5e6936a1a9e7fef1f42e7e2261e5fd5dd3ab6aaee669cc82f16284c6@%3Cuser.syncope.apache.org%3E
>>> [2] https://lists.apache.org/thread.html/947d7261a242cb729aafb551b28fa9bad6c81c2e02eb6f2ec98b7a0a@1428995050@%3Cuser.syncope.apache.org%3E
>>> [3] https://lists.apache.org/thread.html/4662efa8948fc9bba944d8d85ddf902d6c900530ccf78d50df9adb90@1386320489@%3Cuser.syncope.apache.org%3E
>>> [4] https://lists.apache.org/thread.html/be01e1d26de4f7b9ce38026364566dc606496d19eba7e008efa227a0@1375945339@%3Cuser.syncope.apache.org%3E
>>> [5] https://lists.apache.org/thread.html/e4b5727f8506cdca10cf2a6e4332ed23e9c6f73679fa397bb277abe4@1367333293@%3Cuser.syncope.apache.org%3E
>>>
>>> On 19/01/2017 17:53, Colm O hEigeartaigh wrote:
>>>> Hi all,
>>>>
>>>> I'd like to discuss the possibility of supporting dynamic entitlements in Apache Syncope. The goals being to explore if the Apache Syncope community feels that this is a good idea, and if so to try to break the various work items down and start creating JIRAs etc.
>>>>
>>>> Entitlements in Apache Syncope are currently statically defined and are used for internal authorization purposes only. The problem arises when you start considering things like integrating SCIM with Syncope, as the concepts of roles/entitlements in SCIM do not map naturally to groups in Syncope.
>>>>
>>>> So it would be great to be able to map roles/entitlements associated with users directly to the same concepts in Syncope. I don't know whether it might be desirable to have different types of entitlements, e.g. whether we want to maintain a separation between "internal" entitlements used
>>>> for authorization in Syncope, and general entitlements meant for external consumption.
>>>>
>>>> The task would involve some UI work to be able to create entitlements. I'm not sure off-hand if we require REST changes, as we can get the entitlements of a User by getting the roles of the user, and then querying the entitlements associated with the role etc.
>>>>
>>>> Is it possible to associate roles with a group and then have members of that group inherit the entitlements?
>>>>
>>>> WDYT?
>>>>
>>>> Colm.
--
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/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24 jan 2017 18:29:22 CET, Colm O hEigeartaigh <co...@apache.org> ha scritto:
>Hi Francesco,
>
>Thanks for your detailed reply! It's going to take me some time to wrap
>my
>head around all of the details. :-)
Oh, sorry for this, but these ideas have been ringing in my head for quite some time...
I have also others, all in the direction of further improving Syncope, and I am happy to discuss here to clarify, better define, go beyond my direct experience, etc.
>Let me just ask an initial question...when you define privilege
>management
>as " the ability to discover, define and map the rights that users own
>on
>external resources" - are you referring only to resources in the
>Syncope
>terminology here - Identity stores like LDAP etc.?
>
>The reason I ask is that our interest is in being able to define
>privileges
>for external services (say some arbitrary REST service requires a given
>entitlement). Is this use-case accommadated by your proposal, or are we
>talking about separate things here?
Interesting point, indeed.
I admit that below I was exactly referring to Syncope's External Resources, but your sample about REST service is significant.
Let's suppose we introduce the new concept of Application: what kind of communication will Syncope establish with it?
Coming to your sample: what would be the use case of managing in Syncope the privileges available into an external REST service? How would you fetch them? Supposing you're able to associate them to (groups of) users, wow would you push such association to the REST service?
That's why I initially thought to reuse ConnId connectors for this purpose.
WDYT?
Regards.
>On Fri, Jan 20, 2017 at 8:30 AM, Francesco Chicchiriccò
><ilgrosso@apache.org
>> wrote:
>
>>
>> With "dynamic entitlements", I think you are referring to privilege
>> management, e.g. the ability to discover, define and map the rights
>that
>> users own on external resources.
>>
>> I would not confuse this, however, with Syncope entitlements:
>starting
>> with 2.0, in fact, we now finally have a stable mechanism for which
>> entitlements are defined as constants in Java classes (and extensions
>might
>> add their own, as shown by the Camel Provisioning Manager), with
>positive
>> effects on code organization both for Core's Spring Security
>configuration
>> and Admin Console's delegated administration.
>>
>> I think that privilege management is a great addition to Syncope;
>here are
>> few items coming to my mind:
>>
>> 1. privileges must be represented as (JPA) entities, have their own
>TO,
>> REST endpoint, Admin Console management, etc. (as all other entities)
>> 2. privileges should be defined / discovered in external resource(s):
>> resource R1 defines privileges P1, P2, P3; resource R2 defines
>privileges
>> P4,P5; about discovery, ConnId does not provide (yet?) any primitive
>> 3. privileges should be grouped somehow and finally assigned to
>users, but
>> depend on each external resource
>> 4. privileges are not really for users (in the way Syncope defines
>them)
>> but rather for accounts, e.g. the mapped counterpart of a Syncope
>user onto
>> a given external resource.
>>
>> I think we could take the chance to add both privilege management and
>> multi-account management (see SYNCOPE-957): both features require in
>fact a
>> new concept to be introduced in Syncope: accounts.
>>
>> Naturally, I don't see any chance to land all above in 2.0
>(considerable
>> changes involved, even for internal storage); it will be 2.1 at
>least.
>>
>> Regards.
>>
>> [1] https://lists.apache.org/thread.html/5e6936a1a9e7fef1f42e7e2
>> 261e5fd5dd3ab6aaee669cc82f16284c6@%3Cuser.syncope.apache.org%3E
>> [2] https://lists.apache.org/thread.html/947d7261a242cb729aafb55
>>
>1b28fa9bad6c81c2e02eb6f2ec98b7a0a@1428995050@%3Cuser.syncope.apache.org%3E
>> [3] https://lists.apache.org/thread.html/4662efa8948fc9bba944d8d
>>
>85ddf902d6c900530ccf78d50df9adb90@1386320489@%3Cuser.syncope.apache.org%3E
>> [4] https://lists.apache.org/thread.html/be01e1d26de4f7b9ce38026
>>
>364566dc606496d19eba7e008efa227a0@1375945339@%3Cuser.syncope.apache.org%3E
>> [5] https://lists.apache.org/thread.html/e4b5727f8506cdca10cf2a6
>>
>e4332ed23e9c6f73679fa397bb277abe4@1367333293@%3Cuser.syncope.apache.org%3E
>>
>>
>> On 19/01/2017 17:53, Colm O hEigeartaigh wrote:
>>
>>> Hi all,
>>>
>>> I'd like to discuss the possibility of supporting dynamic
>entitlements in
>>> Apache Syncope. The goals being to explore if the Apache Syncope
>community
>>> feels that this is a good idea, and if so to try to break the
>various work
>>> items down and start creating JIRAs etc.
>>>
>>> Entitlements in Apache Syncope are currently statically defined and
>are
>>> used for internal authorization purposes only. The problem arises
>when you
>>> start considering things like integrating SCIM with Syncope, as the
>>> concepts of roles/entitlements in SCIM do not map naturally to
>groups in
>>> Syncope.
>>>
>>> So it would be great to be able to map roles/entitlements associated
>with
>>> users directly to the same concepts in Syncope. I don't know whether
>it
>>> might be desirable to have different types of entitlements, e.g.
>whether
>>> we
>>> want to maintain a separation between "internal" entitlements used
>for
>>> authorization in Syncope, and general entitlements meant for
>external
>>> consumption.
>>>
>>> The task would involve some UI work to be able to create
>entitlements. I'm
>>> not sure off-hand if we require REST changes, as we can get the
>>> entitlements of a User by getting the roles of the user, and then
>querying
>>> the entitlements associated with the role etc.
>>>
>>> Is it possible to associate roles with a group and then have members
>of
>>> that group inherit the entitlements?
>>>
>>> WDYT?
>>>
>>> Colm.
>>>
>>
>> --
>> 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/
>>
>>
>>
--
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/
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
Thanks for your detailed reply! It's going to take me some time to wrap my
head around all of the details. :-)
Let me just ask an initial question...when you define privilege management
as " the ability to discover, define and map the rights that users own on
external resources" - are you referring only to resources in the Syncope
terminology here - Identity stores like LDAP etc.?
The reason I ask is that our interest is in being able to define privileges
for external services (say some arbitrary REST service requires a given
entitlement). Is this use-case accommadated by your proposal, or are we
talking about separate things here?
Colm.
On Fri, Jan 20, 2017 at 8:30 AM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:
>
> With "dynamic entitlements", I think you are referring to privilege
> management, e.g. the ability to discover, define and map the rights that
> users own on external resources.
>
> I would not confuse this, however, with Syncope entitlements: starting
> with 2.0, in fact, we now finally have a stable mechanism for which
> entitlements are defined as constants in Java classes (and extensions might
> add their own, as shown by the Camel Provisioning Manager), with positive
> effects on code organization both for Core's Spring Security configuration
> and Admin Console's delegated administration.
>
> I think that privilege management is a great addition to Syncope; here are
> few items coming to my mind:
>
> 1. privileges must be represented as (JPA) entities, have their own TO,
> REST endpoint, Admin Console management, etc. (as all other entities)
> 2. privileges should be defined / discovered in external resource(s):
> resource R1 defines privileges P1, P2, P3; resource R2 defines privileges
> P4,P5; about discovery, ConnId does not provide (yet?) any primitive
> 3. privileges should be grouped somehow and finally assigned to users, but
> depend on each external resource
> 4. privileges are not really for users (in the way Syncope defines them)
> but rather for accounts, e.g. the mapped counterpart of a Syncope user onto
> a given external resource.
>
> I think we could take the chance to add both privilege management and
> multi-account management (see SYNCOPE-957): both features require in fact a
> new concept to be introduced in Syncope: accounts.
>
> Naturally, I don't see any chance to land all above in 2.0 (considerable
> changes involved, even for internal storage); it will be 2.1 at least.
>
> Regards.
>
> [1] https://lists.apache.org/thread.html/5e6936a1a9e7fef1f42e7e2
> 261e5fd5dd3ab6aaee669cc82f16284c6@%3Cuser.syncope.apache.org%3E
> [2] https://lists.apache.org/thread.html/947d7261a242cb729aafb55
> 1b28fa9bad6c81c2e02eb6f2ec98b7a0a@1428995050@%3Cuser.syncope.apache.org%3E
> [3] https://lists.apache.org/thread.html/4662efa8948fc9bba944d8d
> 85ddf902d6c900530ccf78d50df9adb90@1386320489@%3Cuser.syncope.apache.org%3E
> [4] https://lists.apache.org/thread.html/be01e1d26de4f7b9ce38026
> 364566dc606496d19eba7e008efa227a0@1375945339@%3Cuser.syncope.apache.org%3E
> [5] https://lists.apache.org/thread.html/e4b5727f8506cdca10cf2a6
> e4332ed23e9c6f73679fa397bb277abe4@1367333293@%3Cuser.syncope.apache.org%3E
>
>
> On 19/01/2017 17:53, Colm O hEigeartaigh wrote:
>
>> Hi all,
>>
>> I'd like to discuss the possibility of supporting dynamic entitlements in
>> Apache Syncope. The goals being to explore if the Apache Syncope community
>> feels that this is a good idea, and if so to try to break the various work
>> items down and start creating JIRAs etc.
>>
>> Entitlements in Apache Syncope are currently statically defined and are
>> used for internal authorization purposes only. The problem arises when you
>> start considering things like integrating SCIM with Syncope, as the
>> concepts of roles/entitlements in SCIM do not map naturally to groups in
>> Syncope.
>>
>> So it would be great to be able to map roles/entitlements associated with
>> users directly to the same concepts in Syncope. I don't know whether it
>> might be desirable to have different types of entitlements, e.g. whether
>> we
>> want to maintain a separation between "internal" entitlements used for
>> authorization in Syncope, and general entitlements meant for external
>> consumption.
>>
>> The task would involve some UI work to be able to create entitlements. I'm
>> not sure off-hand if we require REST changes, as we can get the
>> entitlements of a User by getting the roles of the user, and then querying
>> the entitlements associated with the role etc.
>>
>> Is it possible to associate roles with a group and then have members of
>> that group inherit the entitlements?
>>
>> WDYT?
>>
>> Colm.
>>
>
> --
> 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
Re: [DISCUSS] - Support dynamic entitlements in Apache Syncope
Posted by Francesco Chicchiriccò <il...@apache.org>.
Hi Colm,
thanks for starting this discussion, it something that has been popping
out several times in the past ([1][2][3][4][5] just to say some).
With "dynamic entitlements", I think you are referring to privilege
management, e.g. the ability to discover, define and map the rights that
users own on external resources.
I would not confuse this, however, with Syncope entitlements: starting
with 2.0, in fact, we now finally have a stable mechanism for which
entitlements are defined as constants in Java classes (and extensions
might add their own, as shown by the Camel Provisioning Manager), with
positive effects on code organization both for Core's Spring Security
configuration and Admin Console's delegated administration.
I think that privilege management is a great addition to Syncope; here
are few items coming to my mind:
1. privileges must be represented as (JPA) entities, have their own TO,
REST endpoint, Admin Console management, etc. (as all other entities)
2. privileges should be defined / discovered in external resource(s):
resource R1 defines privileges P1, P2, P3; resource R2 defines
privileges P4,P5; about discovery, ConnId does not provide (yet?) any
primitive
3. privileges should be grouped somehow and finally assigned to users,
but depend on each external resource
4. privileges are not really for users (in the way Syncope defines them)
but rather for accounts, e.g. the mapped counterpart of a Syncope user
onto a given external resource.
I think we could take the chance to add both privilege management and
multi-account management (see SYNCOPE-957): both features require in
fact a new concept to be introduced in Syncope: accounts.
Naturally, I don't see any chance to land all above in 2.0 (considerable
changes involved, even for internal storage); it will be 2.1 at least.
Regards.
[1]
https://lists.apache.org/thread.html/5e6936a1a9e7fef1f42e7e2261e5fd5dd3ab6aaee669cc82f16284c6@%3Cuser.syncope.apache.org%3E
[2]
https://lists.apache.org/thread.html/947d7261a242cb729aafb551b28fa9bad6c81c2e02eb6f2ec98b7a0a@1428995050@%3Cuser.syncope.apache.org%3E
[3]
https://lists.apache.org/thread.html/4662efa8948fc9bba944d8d85ddf902d6c900530ccf78d50df9adb90@1386320489@%3Cuser.syncope.apache.org%3E
[4]
https://lists.apache.org/thread.html/be01e1d26de4f7b9ce38026364566dc606496d19eba7e008efa227a0@1375945339@%3Cuser.syncope.apache.org%3E
[5]
https://lists.apache.org/thread.html/e4b5727f8506cdca10cf2a6e4332ed23e9c6f73679fa397bb277abe4@1367333293@%3Cuser.syncope.apache.org%3E
On 19/01/2017 17:53, Colm O hEigeartaigh wrote:
> Hi all,
>
> I'd like to discuss the possibility of supporting dynamic entitlements in
> Apache Syncope. The goals being to explore if the Apache Syncope community
> feels that this is a good idea, and if so to try to break the various work
> items down and start creating JIRAs etc.
>
> Entitlements in Apache Syncope are currently statically defined and are
> used for internal authorization purposes only. The problem arises when you
> start considering things like integrating SCIM with Syncope, as the
> concepts of roles/entitlements in SCIM do not map naturally to groups in
> Syncope.
>
> So it would be great to be able to map roles/entitlements associated with
> users directly to the same concepts in Syncope. I don't know whether it
> might be desirable to have different types of entitlements, e.g. whether we
> want to maintain a separation between "internal" entitlements used for
> authorization in Syncope, and general entitlements meant for external
> consumption.
>
> The task would involve some UI work to be able to create entitlements. I'm
> not sure off-hand if we require REST changes, as we can get the
> entitlements of a User by getting the roles of the user, and then querying
> the entitlements associated with the role etc.
>
> Is it possible to associate roles with a group and then have members of
> that group inherit the entitlements?
>
> WDYT?
>
> Colm.
--
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/