You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2015/03/23 14:26:50 UTC
[DISCUSS] Realms
Hi all,
I've summarized at [1] the feature and changes that I intend to
implement about security realms.
Please take a look and let me know your thoughts: my idea is to start
working on this topic in more or less one month, so we have plenty of
time to discuss.
Regards.
[1] https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Marco Di Sabatino Di Diodoro <ma...@tirasa.net>.
Il 24/03/2015 15:13, Francesco Chicchiriccò ha scritto:
> On 24/03/2015 14:17, Francesco Chicchiriccò wrote:
>> On 24/03/2015 13:25, Marco Di Sabatino Di Diodoro wrote:
>>> Hi Francesco,
>>>
>>> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>>>> Hi all,
>>>> I've summarized at [1] the feature and changes that I intend to
>>>> implement about security realms.
>>>>
>>>> Please take a look and let me know your thoughts: my idea is to
>>>> start working on this topic in more or less one month, so we have
>>>> plenty of time to discuss.
>>>
>>> I agree with you.
>>> In the new security model,why not extend the conceptto the realms?
>>>
>>> For example:
>>>
>>> The realm X has assigned entitlements E_1 ...E_n .Than all usersin
>>> therealm X can exercise entitlements E_1 ...E_n.
>>
>> This can be interesting: only, I would need some solid reasons to not
>> keep the entitlement assignment in a single place (e.g. roles).
>
> After some more thoughts, it seems to me that we might extend the
> proposal at [1] by:
>
> * introducing a new *Group* entity - with purpose of representing
> groups on external resources (attributes, resources, no entitlements)
> * introducing a new *Role* entity - with purpose of assigning
> entitlements (and realm(s) where to apply) to users
>
> Assigning a user to a group would mean create a membership; assigning
> a user to a role will imply granting such user some entitlements.
> One can even think to extend the concept in SYNCOPE-140 (Dynamic role
> memberships) in order to support both groups and roles so that the
> statement above (all users in realm X can exercise entitlement E on
> users from realm Y) can be implemented having:
>
> 1. role R with entitlement E on realm Y
> 2. dynamic assignment of role R to users from realm X
>
> Finally, it seems to me that what is coming out from this discussion
> is a progressive refactoring of the "old" (e.g. up to 1.2.X) role
> concept to the new realm, role and group concepts.
>
> WDYT?
+1
Marco
>
> [1]
> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>
--
Dott. Marco Di Sabatino Di Diodoro
Tel. +39 3939065570
Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
Apache Syncope PMC Member
http://people.apache.org/~mdisabatino/
Re: [DISCUSS] Realms
Posted by Francesco Chicchiriccò <il...@apache.org>.
Hi all,
a quick status update on this topic.
All features discussed below and tracked via SYNCOPE-119 are now on the
master branch, fully implemented on core side.
About console, such changes are so deep that it probably makes no sense
to try to adapt the existing console module, but rather to take input
from this for SYNCOPE-156 and SYNCOPE-120.
For these reasons, I am now working on master branch, where I am about to:
1. rename the current client/console Maven module to
client/old_console, keeping it excluded from build
2. create a new client/console Maven module which will be a Wicket
application built from scratch as per SYNCOPE-156, with panels and other
stuff "migrated" from old_console
Thoughts?
Regards.
On 25/03/2015 11:22, Francesco Chicchiriccò wrote:
> On 24/03/2015 15:13, Francesco Chicchiriccò wrote:
>> [...]
>>
>> After some more thoughts, it seems to me that we might extend the
>> proposal at [1] by:
>>
>> * introducing a new *Group* entity - with purpose of representing
>> groups on external resources (attributes, resources, no entitlements)
>> * introducing a new *Role* entity - with purpose of assigning
>> entitlements (and realm(s) where to apply) to users
>>
>> Assigning a user to a group would mean create a membership; assigning
>> a user to a role will imply granting such user some entitlements.
>> One can even think to extend the concept in SYNCOPE-140 (Dynamic role
>> memberships) in order to support both groups and roles so that the
>> statement above (all users in realm X can exercise entitlement E on
>> users from realm Y) can be implemented having:
>>
>> 1. role R with entitlement E on realm Y
>> 2. dynamic assignment of role R to users from realm X
>>
>> Finally, it seems to me that what is coming out from this discussion
>> is a progressive refactoring of the "old" (e.g. up to 1.2.X) role
>> concept to the new realm, role and group concepts.
>
> FYI I have updated [1] accordingly.
> Regards.
>
>> [1]
>> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24/03/2015 15:13, Francesco Chicchiriccò wrote:
> [...]
>
> After some more thoughts, it seems to me that we might extend the
> proposal at [1] by:
>
> * introducing a new *Group* entity - with purpose of representing
> groups on external resources (attributes, resources, no entitlements)
> * introducing a new *Role* entity - with purpose of assigning
> entitlements (and realm(s) where to apply) to users
>
> Assigning a user to a group would mean create a membership; assigning
> a user to a role will imply granting such user some entitlements.
> One can even think to extend the concept in SYNCOPE-140 (Dynamic role
> memberships) in order to support both groups and roles so that the
> statement above (all users in realm X can exercise entitlement E on
> users from realm Y) can be implemented having:
>
> 1. role R with entitlement E on realm Y
> 2. dynamic assignment of role R to users from realm X
>
> Finally, it seems to me that what is coming out from this discussion
> is a progressive refactoring of the "old" (e.g. up to 1.2.X) role
> concept to the new realm, role and group concepts.
FYI I have updated [1] accordingly.
Regards.
> [1]
> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Fabio Martelli <fa...@gmail.com>.
Il 24/03/2015 15:13, Francesco Chicchiriccò ha scritto:
> On 24/03/2015 14:17, Francesco Chicchiriccò wrote:
>> On 24/03/2015 13:25, Marco Di Sabatino Di Diodoro wrote:
>>> Hi Francesco,
>>>
>>> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>>>> Hi all,
>>>> I've summarized at [1] the feature and changes that I intend to
>>>> implement about security realms.
>>>>
>>>> Please take a look and let me know your thoughts: my idea is to
>>>> start working on this topic in more or less one month, so we have
>>>> plenty of time to discuss.
>>>
>>> I agree with you.
>>> In the new security model,why not extend the conceptto the realms?
>>>
>>> For example:
>>>
>>> The realm X has assigned entitlements E_1 ...E_n .Than all usersin
>>> therealm X can exercise entitlements E_1 ...E_n.
>>
>> This can be interesting: only, I would need some solid reasons to not
>> keep the entitlement assignment in a single place (e.g. roles).
>
> After some more thoughts, it seems to me that we might extend the
> proposal at [1] by:
>
> * introducing a new *Group* entity - with purpose of representing
> groups on external resources (attributes, resources, no entitlements)
> * introducing a new *Role* entity - with purpose of assigning
> entitlements (and realm(s) where to apply) to users
>
> Assigning a user to a group would mean create a membership; assigning
> a user to a role will imply granting such user some entitlements.
> One can even think to extend the concept in SYNCOPE-140 (Dynamic role
> memberships) in order to support both groups and roles so that the
> statement above (all users in realm X can exercise entitlement E on
> users from realm Y) can be implemented having:
>
> 1. role R with entitlement E on realm Y
> 2. dynamic assignment of role R to users from realm X
>
> Finally, it seems to me that what is coming out from this discussion
> is a progressive refactoring of the "old" (e.g. up to 1.2.X) role
> concept to the new realm, role and group concepts.
>
> WDYT?
>
> [1]
> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>
Group and Role concept separation +1
Dynamic role memberships +1
Dynamic (group) memberships +1
Regards,
F.
--
Fabio Martelli
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/
Re: [DISCUSS] Realms
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24/03/2015 14:17, Francesco Chicchiriccò wrote:
> On 24/03/2015 13:25, Marco Di Sabatino Di Diodoro wrote:
>> Hi Francesco,
>>
>> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>>> Hi all,
>>> I've summarized at [1] the feature and changes that I intend to
>>> implement about security realms.
>>>
>>> Please take a look and let me know your thoughts: my idea is to
>>> start working on this topic in more or less one month, so we have
>>> plenty of time to discuss.
>>
>> I agree with you.
>> In the new security model,why not extend the conceptto the realms?
>>
>> For example:
>>
>> The realm X has assigned entitlements E_1 ...E_n .Than all usersin
>> therealm X can exercise entitlements E_1 ...E_n.
>
> This can be interesting: only, I would need some solid reasons to not
> keep the entitlement assignment in a single place (e.g. roles).
After some more thoughts, it seems to me that we might extend the
proposal at [1] by:
* introducing a new *Group* entity - with purpose of representing
groups on external resources (attributes, resources, no entitlements)
* introducing a new *Role* entity - with purpose of assigning
entitlements (and realm(s) where to apply) to users
Assigning a user to a group would mean create a membership; assigning a
user to a role will imply granting such user some entitlements.
One can even think to extend the concept in SYNCOPE-140 (Dynamic role
memberships) in order to support both groups and roles so that the
statement above (all users in realm X can exercise entitlement E on
users from realm Y) can be implemented having:
1. role R with entitlement E on realm Y
2. dynamic assignment of role R to users from realm X
Finally, it seems to me that what is coming out from this discussion is
a progressive refactoring of the "old" (e.g. up to 1.2.X) role concept
to the new realm, role and group concepts.
WDYT?
[1] https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24/03/2015 13:25, Marco Di Sabatino Di Diodoro wrote:
> Hi Francesco,
>
> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>> Hi all,
>> I've summarized at [1] the feature and changes that I intend to
>> implement about security realms.
>>
>> Please take a look and let me know your thoughts: my idea is to start
>> working on this topic in more or less one month, so we have plenty of
>> time to discuss.
>>
>> Regards.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>>
> I agree with you.
> In the new security model,why not extend the conceptto the realms?
>
> For example:
>
> The realm X has assigned entitlements E_1 ...E_n .Than all usersin
> therealm X can exercise entitlements E_1 ...E_n.
This can be interesting: only, I would need some solid reasons to not
keep the entitlement assignment in a single place (e.g. roles).
> In addition to assigne the entitlements to a realm or role, it would
> be nice to define whichrealms an user can exercise the entitlements.
This is precisely what I mean, see the example at the bottom of the wiki
page, item "B".
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Marco Di Sabatino Di Diodoro <ma...@tirasa.net>.
Hi Francesco,
Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
> Hi all,
> I've summarized at [1] the feature and changes that I intend to
> implement about security realms.
>
> Please take a look and let me know your thoughts: my idea is to start
> working on this topic in more or less one month, so we have plenty of
> time to discuss.
>
> Regards.
>
> [1]
> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>
I agree with you.
In the new security model,why not extend the conceptto the realms?
For example:
The realm X has assigned entitlements E_1 ...E_n .Than all usersin
therealm X can exercise entitlements E_1 ...E_n.
In addition to assigne the entitlements to a realm or role, it would be
nice to define whichrealms an user can exercise the entitlements.
Marco
--
Dott. Marco Di Sabatino Di Diodoro
Tel. +39 3939065570
Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
Apache Syncope PMC Member
http://people.apache.org/~mdisabatino/
Re: [DISCUSS] Realms
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24/03/2015 14:55, Fabio Martelli wrote:
> [...]
>> Alternatively, why not moving the realm from path to request
>> parameter, e.g. from
>>
>> GET /users/a/b
>>
>> to
>>
>> GET /users?realm=/a/b
>>
>> WDYT?
>>
> Hey, it sounds with me.
> Now I get your reasons and I do think that this is a good compromise.
>
> +1
FYI I have updated the REST API section at [1] by using request
parameter (?realm=) or matrix parameter (;realm=) depending on the context.
Regards.
[1] https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Fabio Martelli <fa...@gmail.com>.
Il 24/03/2015 14:31, Francesco Chicchiriccò ha scritto:
> On 24/03/2015 14:14, Francesco Chicchiriccò wrote:
>> On 24/03/2015 14:10, Fabio Martelli wrote:
>>> Il 24/03/2015 13:16, Francesco Chicchiriccò ha scritto:
>>>> On 24/03/2015 12:28, Fabio Martelli wrote:
>>>>> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>>>>>> Hi all,
>>>>>> I've summarized at [1] the feature and changes that I intend to
>>>>>> implement about security realms.
>>>>>>
>>>>>> Please take a look and let me know your thoughts: my idea is to
>>>>>> start working on this topic in more or less one month, so we have
>>>>>> plenty of time to discuss.
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>> [1]
>>>>>> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>>>>>>
>>>>>>
>>>>> Francesco, as you already know, you have my sponsorship for this
>>>>> new feature. Thank you for the wiki page.
>>>>> Just a comment: I'm not sure about the suggested REST API change.
>>>>>
>>>>> For example, to get users under a certain path you are proposing
>>>>> to have a request like as
>>>>>
>>>>> GET /users/a/b
>>>>>
>>>>> Why not the following?
>>>>>
>>>>> GET /a/b/users
>>>>>
>>>>> Personally, I'd prefer to have the path before in every request;
>>>>> something like as below.
>>>>
>>>> Why? Because otherwise we would need to implement custom routing of
>>>> each and every single REST call :-)
>>>>
>>> Hi Francesco, thanks for your prompt reply.
>>> I was suggesting something like as below.
>>>
>>> @Path("/{path:.*}/users)
>>> public Response get(@PathParam("path") final String path) {
>>> ......
>>> }
>>>
>>> Am I missing something?
>>
>> Currently "users" is bound to the whole UserService class (and
>> similar for other 10+ services): are you suggesting we need to
>> completely review / rewrite our REST API level?
>
> Alternatively, why not moving the realm from path to request
> parameter, e.g. from
>
> GET /users/a/b
>
> to
>
> GET /users?realm=/a/b
>
> WDYT?
>
Hey, it sounds with me.
Now I get your reasons and I do think that this is a good compromise.
+1
Best regards,
F.
--
Fabio Martelli
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/
Re: [DISCUSS] Realms
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24/03/2015 14:14, Francesco Chicchiriccò wrote:
> On 24/03/2015 14:10, Fabio Martelli wrote:
>> Il 24/03/2015 13:16, Francesco Chicchiriccò ha scritto:
>>> On 24/03/2015 12:28, Fabio Martelli wrote:
>>>> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>>>>> Hi all,
>>>>> I've summarized at [1] the feature and changes that I intend to
>>>>> implement about security realms.
>>>>>
>>>>> Please take a look and let me know your thoughts: my idea is to
>>>>> start working on this topic in more or less one month, so we have
>>>>> plenty of time to discuss.
>>>>>
>>>>> Regards.
>>>>>
>>>>> [1]
>>>>> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>>>>>
>>>>>
>>>> Francesco, as you already know, you have my sponsorship for this
>>>> new feature. Thank you for the wiki page.
>>>> Just a comment: I'm not sure about the suggested REST API change.
>>>>
>>>> For example, to get users under a certain path you are proposing to
>>>> have a request like as
>>>>
>>>> GET /users/a/b
>>>>
>>>> Why not the following?
>>>>
>>>> GET /a/b/users
>>>>
>>>> Personally, I'd prefer to have the path before in every request;
>>>> something like as below.
>>>
>>> Why? Because otherwise we would need to implement custom routing of
>>> each and every single REST call :-)
>>>
>> Hi Francesco, thanks for your prompt reply.
>> I was suggesting something like as below.
>>
>> @Path("/{path:.*}/users)
>> public Response get(@PathParam("path") final String path) {
>> ......
>> }
>>
>> Am I missing something?
>
> Currently "users" is bound to the whole UserService class (and similar
> for other 10+ services): are you suggesting we need to completely
> review / rewrite our REST API level?
Alternatively, why not moving the realm from path to request parameter,
e.g. from
GET /users/a/b
to
GET /users?realm=/a/b
WDYT?
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24/03/2015 14:10, Fabio Martelli wrote:
> Il 24/03/2015 13:16, Francesco Chicchiriccò ha scritto:
>> On 24/03/2015 12:28, Fabio Martelli wrote:
>>> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>>>> Hi all,
>>>> I've summarized at [1] the feature and changes that I intend to
>>>> implement about security realms.
>>>>
>>>> Please take a look and let me know your thoughts: my idea is to
>>>> start working on this topic in more or less one month, so we have
>>>> plenty of time to discuss.
>>>>
>>>> Regards.
>>>>
>>>> [1]
>>>> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>>>>
>>>>
>>> Francesco, as you already know, you have my sponsorship for this new
>>> feature. Thank you for the wiki page.
>>> Just a comment: I'm not sure about the suggested REST API change.
>>>
>>> For example, to get users under a certain path you are proposing to
>>> have a request like as
>>>
>>> GET /users/a/b
>>>
>>> Why not the following?
>>>
>>> GET /a/b/users
>>>
>>> Personally, I'd prefer to have the path before in every request;
>>> something like as below.
>>
>> Why? Because otherwise we would need to implement custom routing of
>> each and every single REST call :-)
>>
> Hi Francesco, thanks for your prompt reply.
> I was suggesting something like as below.
>
> @Path("/{path:.*}/users)
> public Response get(@PathParam("path") final String path) {
> ......
> }
>
> Am I missing something?
Currently "users" is bound to the whole UserService class (and similar
for other 10+ services): are you suggesting we need to completely review
/ rewrite our REST API level?
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Fabio Martelli <fa...@gmail.com>.
Il 24/03/2015 13:16, Francesco Chicchiriccò ha scritto:
> On 24/03/2015 12:28, Fabio Martelli wrote:
>> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>>> Hi all,
>>> I've summarized at [1] the feature and changes that I intend to
>>> implement about security realms.
>>>
>>> Please take a look and let me know your thoughts: my idea is to
>>> start working on this topic in more or less one month, so we have
>>> plenty of time to discuss.
>>>
>>> Regards.
>>>
>>> [1]
>>> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>>>
>>>
>> Francesco, as you already know, you have my sponsorship for this new
>> feature. Thank you for the wiki page.
>> Just a comment: I'm not sure about the suggested REST API change.
>>
>> For example, to get users under a certain path you are proposing to
>> have a request like as
>>
>> GET /users/a/b
>>
>> Why not the following?
>>
>> GET /a/b/users
>>
>> Personally, I'd prefer to have the path before in every request;
>> something like as below.
>
> Why? Because otherwise we would need to implement custom routing of
> each and every single REST call :-)
>
Hi Francesco, thanks for your prompt reply.
I was suggesting something like as below.
@Path("/{path:.*}/users)
public Response get(@PathParam("path") final String path) {
......
}
Am I missing something?
Regards,
F.
--
Fabio Martelli
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/
Re: [DISCUSS] Realms
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 24/03/2015 12:28, Fabio Martelli wrote:
> Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
>> Hi all,
>> I've summarized at [1] the feature and changes that I intend to
>> implement about security realms.
>>
>> Please take a look and let me know your thoughts: my idea is to start
>> working on this topic in more or less one month, so we have plenty of
>> time to discuss.
>>
>> Regards.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>>
> Francesco, as you already know, you have my sponsorship for this new
> feature. Thank you for the wiki page.
> Just a comment: I'm not sure about the suggested REST API change.
>
> For example, to get users under a certain path you are proposing to
> have a request like as
>
> GET /users/a/b
>
> Why not the following?
>
> GET /a/b/users
>
> Personally, I'd prefer to have the path before in every request;
> something like as below.
Why? Because otherwise we would need to implement custom routing of each
and every single REST call :-)
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Realms
Posted by Fabio Martelli <fa...@gmail.com>.
Il 23/03/2015 14:26, Francesco Chicchiriccò ha scritto:
> Hi all,
> I've summarized at [1] the feature and changes that I intend to
> implement about security realms.
>
> Please take a look and let me know your thoughts: my idea is to start
> working on this topic in more or less one month, so we have plenty of
> time to discuss.
>
> Regards.
>
> [1]
> https://cwiki.apache.org/confluence/display/SYNCOPE/%5BDISCUSS%5D+Realms
>
Francesco, as you already know, you have my sponsorship for this new
feature. Thank you for the wiki page.
Just a comment: I'm not sure about the suggested REST API change.
For example, to get users under a certain path you are proposing to have
a request like as
GET /users/a/b
Why not the following?
GET /a/b/users
Personally, I'd prefer to have the path before in every request;
something like as below.
Regards,
F.
GET /realms
GET /a/b/realms
list realms starting at given root:
all realms in the former case, realms rooted at /a/b in the latter case
GET /a/b/c read realm /a/b/c
POST /a/b create realm under /a/b
PUT /a/b/c/d
update realm /a/b/c/d
DELETE /a/b delete realm /a/b (and all sub-realms)
GET /users GET /users
GET /a/b/users list users under the given realm (e.g. assigned to given
realm and related sub-realms):
all users in the former case, users in realm /a/b (all all sub-realms)
in the latter case
POST /users POST /users
POST /a/b/users create user under the given realm:
root realm in the former case, /a/b in the latter case
PUT /a/b/users/{userId} move user with id {userId} under realm /a/b
GET /users/search GET /users/search
GET /a/b/users/search search users under the given realm:
root realm in the former case, /a/b in the latter case
GET /roles GET /roles
GET /a/b/roles see users
POST /roles
POST /roles
POST /a/b/roles
see users
PUT /a/b/roles/{roleId} move role with id {roleId} under realm /a/b
GET /roles/search GET /roles/search
GET /a/b/roles/search see users
GET /roles/{roleId}/parent
GET/roles/{roleId}/children
--
Fabio Martelli
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/