You are viewing a plain text version of this content. The canonical link for it is here.
Posted to photark-dev@incubator.apache.org by Suhothayan Sriskandarajah <su...@gmail.com> on 2010/06/18 15:33:34 UTC
Photark Authorization using Role Based Access Control
I believe the authentication is now stable in Photark.
I'm now going to start working on implementing a simple "Role Based
Access Control" next, and
here is the initial approach i have in mind...
I thought of creating some well defined mutually exclusive roles
1. Super admin Role : have only 1 user (The one who login from
FORM authentication)
2. Registered user Role
3. Unregistered user Role : the users who are not logged in.
4. Blocked user Role
And there will be other normal roles which are kind of a groups (groupRoles)
these can be created by uses in "Registered user Role" and "Super admin Role"
for e.g.
a RegisteredUser1 in "Registered user Role" can create a groupRole
called myFriends and add user1, user2 & user3
and sets myFriends groupRole permissions to allow users to add/remove
images from AlbumA and AlbumB
provided the users user1, user2 & user3 are also in the Registered
user Role they can execute the given permissions
and only the RegisteredUser1 and the Super Admin have the rights to
view and edit the myFriends Role (it's users and permissions)
each of these roles will have permissions
1. Super admin Role :
* change users from one role to another (Registered to Blocked and other)
* view and delete all albums, image, album descriptions of all users
* create and manage groupRoles
2. Registered user Role :
* can create an album
* can delete his albums, edit album description and add/remove images
from his album
* create and mange groupRoles (add/remove users to it and change
permissions) , he can manage only groupRoles he created
3. Unregistered user Role :
* view the albums (only giving access to view by Unregistered user
Role) (public albums)
4. Blocked user Role :
* same as Unregistered user Role
the roles are arranged in a hierarchy where
Super Admin Role (top)
Group Roles
Registered user Role
Unregistered user Role
Blocked user Role
the basic permissions for now
*adding images
*removing images
*creating albums
*deleting albums
*editing album description
I think this model is scalable in future.
Please do give your thoughts on this and guide me in the correct path
Suho
Re: Photark Authorization using Role Based Access Control
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Jun 24, 2010 at 9:45 PM, Suhothayan Sriskandarajah
<su...@gmail.com> wrote:
> On 25 June 2010 09:45, Avdhesh Yadav <av...@avdheshyadav.com> wrote:
>> Roles and Permissions can be stored in the JCR repository and configured
>> from the Admin UI.From Admin UI we can define/delete/edit permissions ,
>> roles and assign permissions to roles.
>>
>>
Java EE has the notion of Roles, does it make sense to look into using
that instead of a home grown solutions ?
>
> Super admin Role, Registered user Role, Unregistered user Role,
> Blocked user Role
> are hard coded
See comments above.
> Super admin Role will have all possible rights..
> Specially the right to configure the permissions of other roles (
> Registered user Role, Unregistered user Role, Blocked user Role and
> group-roles)
>
> The group-roles can be configured only by the super admin and registered user.
>
> I'm thinking of adding a div to the upload.html page. when "manage
> roles" button is pressed the present adminGallery div will be hidden
> and the new div will appear for handling roles
>
> When we use Json rpc there is no way for the back end to identify who
> is sending the request, as it cant access the session.
> So I thought of implementing a token system. where a token will be
> given to the front end at the page loading using an http call. Then
> the front end will send the token with all the Json request so the
> back end can process the request according to the session (the user
> and his permissions)
>
What I had done in the past was to configure specific operations (in
our case probably the whole service) with SCA policy, saying it
requires a specific role and the Tuscany runtime was handling the
authorization delegating to the Java EE server to handle provide a
list of roles for the given user.
<component name="Catalog">
<implementation.java class="services.FruitsCatalogImpl">
<operation name="get" policySets="allowManager" />
</implementation.java>
<property name="currencyCode">USD</property>
<service name="Catalog">
<operation name="get" requires="authentication"/>
<tuscany:binding.jsonrpc/>
</service>
<reference name="currencyConverter" target="CurrencyConverter" />
</component>
Anyway, the policy thing is really just food for thought, as it would
require LDAP integration or some kind of User Repository integration
and would limit the type of servers we could run PhotArk.
[1] https://svn.apache.org/repos/asf/tuscany/sandbox/lresende/sca-1.x/samples/store-secure-webapp/
[2] https://svn.apache.org/repos/asf/tuscany/sandbox/lresende/sca-1.x/samples/store-secure-webapp/src/main/resources/store.composite
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Photark Authorization using Role Based Access Control
Posted by Suhothayan Sriskandarajah <su...@gmail.com>.
On 25 June 2010 09:45, Avdhesh Yadav <av...@avdheshyadav.com> wrote:
> Roles and Permissions can be stored in the JCR repository and configured
> from the Admin UI.From Admin UI we can define/delete/edit permissions ,
> roles and assign permissions to roles.
>
>
Super admin Role, Registered user Role, Unregistered user Role,
Blocked user Role
are hard coded
Super admin Role will have all possible rights..
Specially the right to configure the permissions of other roles (
Registered user Role, Unregistered user Role, Blocked user Role and
group-roles)
The group-roles can be configured only by the super admin and registered user.
I'm thinking of adding a div to the upload.html page. when "manage
roles" button is pressed the present adminGallery div will be hidden
and the new div will appear for handling roles
When we use Json rpc there is no way for the back end to identify who
is sending the request, as it cant access the session.
So I thought of implementing a token system. where a token will be
given to the front end at the page loading using an http call. Then
the front end will send the token with all the Json request so the
back end can process the request according to the session (the user
and his permissions)
suho
> On Thu, Jun 24, 2010 at 10:34 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Thu, Jun 24, 2010 at 9:53 AM, Avdhesh Yadav <av...@avdheshyadav.com>
>> wrote:
>> > I agree with this approach.
>> >
>> > +1
>> >
>> >
>> > On Fri, Jun 18, 2010 at 9:03 PM, Suhothayan Sriskandarajah <
>> > suhothayan@gmail.com> wrote:
>> >
>> >> I believe the authentication is now stable in Photark.
>> >> I'm now going to start working on implementing a simple "Role Based
>> >> Access Control" next, and
>> >> here is the initial approach i have in mind...
>> >>
>> >> I thought of creating some well defined mutually exclusive roles
>> >> 1. Super admin Role : have only 1 user (The one who login from
>> >> FORM authentication)
>> >> 2. Registered user Role
>> >> 3. Unregistered user Role : the users who are not logged in.
>> >> 4. Blocked user Role
>> >>
>> >> And there will be other normal roles which are kind of a groups
>> >> (groupRoles)
>> >> these can be created by uses in "Registered user Role" and "Super admin
>> >> Role"
>> >> for e.g.
>> >> a RegisteredUser1 in "Registered user Role" can create a groupRole
>> >> called myFriends and add user1, user2 & user3
>> >> and sets myFriends groupRole permissions to allow users to add/remove
>> >> images from AlbumA and AlbumB
>> >>
>> >> provided the users user1, user2 & user3 are also in the Registered
>> >> user Role they can execute the given permissions
>> >> and only the RegisteredUser1 and the Super Admin have the rights to
>> >> view and edit the myFriends Role (it's users and permissions)
>> >>
>> >>
>> >> each of these roles will have permissions
>> >> 1. Super admin Role :
>> >> * change users from one role to another (Registered to Blocked and
>> other)
>> >> * view and delete all albums, image, album descriptions of all users
>> >> * create and manage groupRoles
>> >>
>> >> 2. Registered user Role :
>> >> * can create an album
>> >> * can delete his albums, edit album description and add/remove images
>> >> from his album
>> >> * create and mange groupRoles (add/remove users to it and change
>> >> permissions) , he can manage only groupRoles he created
>> >>
>> >> 3. Unregistered user Role :
>> >> * view the albums (only giving access to view by Unregistered user
>> >> Role) (public albums)
>> >>
>> >> 4. Blocked user Role :
>> >> * same as Unregistered user Role
>> >>
>> >> the roles are arranged in a hierarchy where
>> >> Super Admin Role (top)
>> >> Group Roles
>> >> Registered user Role
>> >> Unregistered user Role
>> >> Blocked user Role
>> >>
>> >> the basic permissions for now
>> >> *adding images
>> >> *removing images
>> >> *creating albums
>> >> *deleting albums
>> >> *editing album description
>> >>
>> >> I think this model is scalable in future.
>> >> Please do give your thoughts on this and guide me in the correct path
>> >>
>> >> Suho
>> >>
>> >
>> >
>> >
>>
>> How are roles configured ? How are roles enforced ?
>>
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>>
>
>
>
> --
> Avdhesh Yadav
> http://www.avdheshyadav.com
> http://twitter.com/yadavavdhesh
>
Re: Photark Authorization using Role Based Access Control
Posted by Avdhesh Yadav <av...@avdheshyadav.com>.
Roles and Permissions can be stored in the JCR repository and configured
from the Admin UI.From Admin UI we can define/delete/edit permissions ,
roles and assign permissions to roles.
On Thu, Jun 24, 2010 at 10:34 PM, Luciano Resende <lu...@gmail.com>wrote:
> On Thu, Jun 24, 2010 at 9:53 AM, Avdhesh Yadav <av...@avdheshyadav.com>
> wrote:
> > I agree with this approach.
> >
> > +1
> >
> >
> > On Fri, Jun 18, 2010 at 9:03 PM, Suhothayan Sriskandarajah <
> > suhothayan@gmail.com> wrote:
> >
> >> I believe the authentication is now stable in Photark.
> >> I'm now going to start working on implementing a simple "Role Based
> >> Access Control" next, and
> >> here is the initial approach i have in mind...
> >>
> >> I thought of creating some well defined mutually exclusive roles
> >> 1. Super admin Role : have only 1 user (The one who login from
> >> FORM authentication)
> >> 2. Registered user Role
> >> 3. Unregistered user Role : the users who are not logged in.
> >> 4. Blocked user Role
> >>
> >> And there will be other normal roles which are kind of a groups
> >> (groupRoles)
> >> these can be created by uses in "Registered user Role" and "Super admin
> >> Role"
> >> for e.g.
> >> a RegisteredUser1 in "Registered user Role" can create a groupRole
> >> called myFriends and add user1, user2 & user3
> >> and sets myFriends groupRole permissions to allow users to add/remove
> >> images from AlbumA and AlbumB
> >>
> >> provided the users user1, user2 & user3 are also in the Registered
> >> user Role they can execute the given permissions
> >> and only the RegisteredUser1 and the Super Admin have the rights to
> >> view and edit the myFriends Role (it's users and permissions)
> >>
> >>
> >> each of these roles will have permissions
> >> 1. Super admin Role :
> >> * change users from one role to another (Registered to Blocked and
> other)
> >> * view and delete all albums, image, album descriptions of all users
> >> * create and manage groupRoles
> >>
> >> 2. Registered user Role :
> >> * can create an album
> >> * can delete his albums, edit album description and add/remove images
> >> from his album
> >> * create and mange groupRoles (add/remove users to it and change
> >> permissions) , he can manage only groupRoles he created
> >>
> >> 3. Unregistered user Role :
> >> * view the albums (only giving access to view by Unregistered user
> >> Role) (public albums)
> >>
> >> 4. Blocked user Role :
> >> * same as Unregistered user Role
> >>
> >> the roles are arranged in a hierarchy where
> >> Super Admin Role (top)
> >> Group Roles
> >> Registered user Role
> >> Unregistered user Role
> >> Blocked user Role
> >>
> >> the basic permissions for now
> >> *adding images
> >> *removing images
> >> *creating albums
> >> *deleting albums
> >> *editing album description
> >>
> >> I think this model is scalable in future.
> >> Please do give your thoughts on this and guide me in the correct path
> >>
> >> Suho
> >>
> >
> >
> >
>
> How are roles configured ? How are roles enforced ?
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
--
Avdhesh Yadav
http://www.avdheshyadav.com
http://twitter.com/yadavavdhesh
Re: Photark Authorization using Role Based Access Control
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Jun 24, 2010 at 9:53 AM, Avdhesh Yadav <av...@avdheshyadav.com> wrote:
> I agree with this approach.
>
> +1
>
>
> On Fri, Jun 18, 2010 at 9:03 PM, Suhothayan Sriskandarajah <
> suhothayan@gmail.com> wrote:
>
>> I believe the authentication is now stable in Photark.
>> I'm now going to start working on implementing a simple "Role Based
>> Access Control" next, and
>> here is the initial approach i have in mind...
>>
>> I thought of creating some well defined mutually exclusive roles
>> 1. Super admin Role : have only 1 user (The one who login from
>> FORM authentication)
>> 2. Registered user Role
>> 3. Unregistered user Role : the users who are not logged in.
>> 4. Blocked user Role
>>
>> And there will be other normal roles which are kind of a groups
>> (groupRoles)
>> these can be created by uses in "Registered user Role" and "Super admin
>> Role"
>> for e.g.
>> a RegisteredUser1 in "Registered user Role" can create a groupRole
>> called myFriends and add user1, user2 & user3
>> and sets myFriends groupRole permissions to allow users to add/remove
>> images from AlbumA and AlbumB
>>
>> provided the users user1, user2 & user3 are also in the Registered
>> user Role they can execute the given permissions
>> and only the RegisteredUser1 and the Super Admin have the rights to
>> view and edit the myFriends Role (it's users and permissions)
>>
>>
>> each of these roles will have permissions
>> 1. Super admin Role :
>> * change users from one role to another (Registered to Blocked and other)
>> * view and delete all albums, image, album descriptions of all users
>> * create and manage groupRoles
>>
>> 2. Registered user Role :
>> * can create an album
>> * can delete his albums, edit album description and add/remove images
>> from his album
>> * create and mange groupRoles (add/remove users to it and change
>> permissions) , he can manage only groupRoles he created
>>
>> 3. Unregistered user Role :
>> * view the albums (only giving access to view by Unregistered user
>> Role) (public albums)
>>
>> 4. Blocked user Role :
>> * same as Unregistered user Role
>>
>> the roles are arranged in a hierarchy where
>> Super Admin Role (top)
>> Group Roles
>> Registered user Role
>> Unregistered user Role
>> Blocked user Role
>>
>> the basic permissions for now
>> *adding images
>> *removing images
>> *creating albums
>> *deleting albums
>> *editing album description
>>
>> I think this model is scalable in future.
>> Please do give your thoughts on this and guide me in the correct path
>>
>> Suho
>>
>
>
>
How are roles configured ? How are roles enforced ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Photark Authorization using Role Based Access Control
Posted by Avdhesh Yadav <av...@avdheshyadav.com>.
I agree with this approach.
+1
On Fri, Jun 18, 2010 at 9:03 PM, Suhothayan Sriskandarajah <
suhothayan@gmail.com> wrote:
> I believe the authentication is now stable in Photark.
> I'm now going to start working on implementing a simple "Role Based
> Access Control" next, and
> here is the initial approach i have in mind...
>
> I thought of creating some well defined mutually exclusive roles
> 1. Super admin Role : have only 1 user (The one who login from
> FORM authentication)
> 2. Registered user Role
> 3. Unregistered user Role : the users who are not logged in.
> 4. Blocked user Role
>
> And there will be other normal roles which are kind of a groups
> (groupRoles)
> these can be created by uses in "Registered user Role" and "Super admin
> Role"
> for e.g.
> a RegisteredUser1 in "Registered user Role" can create a groupRole
> called myFriends and add user1, user2 & user3
> and sets myFriends groupRole permissions to allow users to add/remove
> images from AlbumA and AlbumB
>
> provided the users user1, user2 & user3 are also in the Registered
> user Role they can execute the given permissions
> and only the RegisteredUser1 and the Super Admin have the rights to
> view and edit the myFriends Role (it's users and permissions)
>
>
> each of these roles will have permissions
> 1. Super admin Role :
> * change users from one role to another (Registered to Blocked and other)
> * view and delete all albums, image, album descriptions of all users
> * create and manage groupRoles
>
> 2. Registered user Role :
> * can create an album
> * can delete his albums, edit album description and add/remove images
> from his album
> * create and mange groupRoles (add/remove users to it and change
> permissions) , he can manage only groupRoles he created
>
> 3. Unregistered user Role :
> * view the albums (only giving access to view by Unregistered user
> Role) (public albums)
>
> 4. Blocked user Role :
> * same as Unregistered user Role
>
> the roles are arranged in a hierarchy where
> Super Admin Role (top)
> Group Roles
> Registered user Role
> Unregistered user Role
> Blocked user Role
>
> the basic permissions for now
> *adding images
> *removing images
> *creating albums
> *deleting albums
> *editing album description
>
> I think this model is scalable in future.
> Please do give your thoughts on this and guide me in the correct path
>
> Suho
>
--
Avdhesh Yadav
http://www.avdheshyadav.com
http://twitter.com/yadavavdhesh