incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avdhesh Yadav <...@avdheshyadav.com>
Subject Re: Integrating OpenID and Providing User Management to PhotArk
Date Fri, 13 Aug 2010 05:24:23 GMT
Hi to All,

I think now we have basic Authentication And Authorization module ready.

*Features*
1) Authentication using OpenId.
2) Super Admin can create new Roles e.g editor,moderator,viewer etc
3) Super admin can block and unblock any user.
4) Registered User can create groups like ,friends,family etc.
5) Registered can now control the visibility of the albums.

I have tested this patch and if all agree I am looking forward to Commit
this patch in the Trunk.

Here is my +1

-- 
Avdhesh Yadav
http://www.avdheshyadav.com
http://twitter.com/yadavavdhesh

On Tue, Aug 10, 2010 at 9:49 PM, Suhothayan Sriskandarajah <
suhothayan@gmail.com> wrote:

> On 10 August 2010 15:03, Suhothayan Sriskandarajah <suhothayan@gmail.com
> >wrote:
>
> >
> >
> > On 20 May 2010 11:22, Avdhesh Yadav <avd@avdheshyadav.com> wrote:
> >
> >> I have added my comments on Jirra.
> >>
> >> Others should also review this patch and comments are welcome.
> >>
> >>
> > I have finished the development part of my gsoc module
> > where I have implemented authorization according to Role based access
> > control
> > now I have attached a patch on jira [0]
> >
> > Please test this patch and if you come across any issues or bugs please
> let
> > me know, so i can fix those issues
> >
> > I'm also looking forward to "update" the wiki i wrote on the PhotArk JCR
> > Repository Structure[1]
> > and the wiki on Integrating OpenID and Providing User Management to
> > PhotArk[2]
> > Here I'll try my best to document all the work I have done.
> >
> > [0]
> >
> https://issues.apache.org/jira/secure/attachment/12451656/authorization_final_patch_with_corrections.patch
> >
> sorry there was a build failure in the patch so I have added a new one;
>
> https://issues.apache.org/jira/secure/attachment/12451683/authorization_final_patch_with_corrections_without_build_failure.patch
>
> suho
>
>
> > [1]
> >
> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/Repository+Structure
> >
> > [2]
> >
> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/Integrating+OpenID+and+Providing+User+Management+to+PhotArk
> >
> >
> > Suho
> >
> >  --
> >>
> >> Avdhesh Yadav
> >> http://www.avdheshyadav.com
> >> http://twitter.com/yadavavdhesh
> >>
> >> On Thu, May 20, 2010 at 4:03 AM, Suhothayan Sriskandarajah <
> >> suhothayan@gmail.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > I have attached a patch (Authentication_improved1.patch)  on jira for
> >> the
> >> > issue PHOTARK-20 [1]
> >> >
> >> > Here I have implemented the authentication part for PhotArk.
> >> > I have used two way Authentication here,
> >> >
> >> > 1- Through OpenID
> >> > 2- Through Tomcat
> >> >
> >> > The two way authentication is introduced because of the decision to
> have
> >> a
> >> > Super admin.
> >> > Super admin will be the person who will have the highest privilege,
> >> > e.g. he can block the users, delete and moderate the content etc.
> >> >
> >> > Therefore Super admin needs more control over the system than relying
> on
> >> a
> >> > 3rd party for authentication. The tomcat login is used to satisfy this
> >> > condition.
> >> >
> >> > I have used 3 Servlets where one for each logins (tomcat,openId) and
> one
> >> > for
> >> > logout.
> >> > I have also used a filter to manager these two authentications and
> block
> >> > direct access to the upload.html.
> >> > A dummy AccessManager Class was introduced in order to help the
> >> > authentication and this will be improved in future to handle
> >> authorization
> >> > for PhotArk.
> >> >
> >> > The wiki contains Class Diagram and an Activity diagram for this
> >> > implementation [2]
> >> >
> >> > please review this and if you have any issues let me know I'll  fix
> >> them.
> >> >
> >> > [1] https://issues.apache.org/jira/browse/PHOTARK-20
> >> > [2]
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/Integrating+OpenID+and+Providing+User+Management+to+PhotArk
> >> >
> >> > Regards
> >> > Suho
> >> >
> >> > On 2 May 2010 15:22, Suhothayan Sriskandarajah <suhothayan@gmail.com>
> >> > wrote:
> >> >
> >> > >
> >> > >
> >> > > On 2 May 2010 00:36, Avdhesh <avd@avdheshyadav.com> wrote:
> >> > >
> >> > >> On 05/01/2010 05:36 PM, Suhothayan Sriskandarajah wrote:
> >> > >>
> >> > >>> hi,
> >> > >>>
> >> > >>> To support my gsoc project i have created the followig WIKI
> >> > >>>
> >> > >>>
> >> > >>>
> >> >
> >>
> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/Integrating+OpenID+and+Providing+User+Management+to+PhotArk
> >> > >>>
> >> > >>> please go through my updates here and give your suggetions
on
> >> > >>> improvements
> >> > >>> and correct me if i have gone wrong some where.
> >> > >>>
> >> > >>> Thanks
> >> > >>> Suho
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >> Hi,
> >> > >>
> >> > >> I consider following relationship in Photark.
> >> > >> User 1->n Albums 1->n Picture.
> >> > >>
> >> > >> Comments
> >> > >>
> >> > >> - Whats the purpose of AuthorizedUser class?.
> >> > >>
> >> > >> Its the same as the user class and it has no additional advantage.
> so
> >> I
> >> > > have removed it.
> >> > >
> >> > > - Where you put the logic of accessing correct album.Inside the
> Access
> >> > >> manager class or inside the user manager class.
> >> > >>
> >> > >> its  in the AccessManager Class; UserManager is for creating
> deleting
> >> > > users and in future if we are implementing relationships among users
> >> we
> >> > can
> >> > > manage that through UserManager
> >> > >
> >> > >>
> >> > >> Suggestions.
> >> > >>
> >> > >> I think you make Access Manager centralized and so it acts as
> >> > gateway.You
> >> > >> can introduce a immutable AccessList object.
> >> > >>
> >> > > done
> >> > >
> >> > >> Album can have owner attribute which identifies who created the
> >> album.
> >> > and
> >> > >> a list of permitted Users and can also have a attribute to identify
> >> it
> >> > >> public , private or protected.
> >> > >>
> >> > > yes, owner and permittedUsers are added
> >> > > but I'm not having attribute to identify it public , private or
> >> > protected.
> >> > > Instead I'm implementing the permittedUsers as a Map. which contains
> >> > > UserOpenID and that user's resourcePermission.
> >> > > eg
> >> > > openID1 : (view&comment)
> >> > > openID2 : (view)
> >> > > openID3 : (blocked)
> >> > > openID4 : (modify)
> >> > > GuestUser : (blocked)           // this is a special user : whoever
> >> not
> >> > in
> >> > > this list
> >> > >                                                           (many be
> >> > > authenticated or not) will fall here
> >> > >
> >> > > here resourcePermissions are;  blocked< view < view&comment
< modify
> >> > >
> >> > > I'm using the method ;
> >> > > setAllUsersResourcePermission(Permission resourcePermission);
> >> > > through this if all the users are given "view" resourcePermission
it
> >> will
> >> > > be like "Public" mode
> >> > > and if all the users are given "blocked" resourcePermission it will
> be
> >> > like
> >> > > "Private" mode
> >> > > otherwise its will be like "Protected" mode.
> >> > >
> >> > > AccessManager uses the accessList of the user and fetches the
> correct
> >> > >> albums from the repository.
> >> > >>
> >> > >> yes, this is also implemented.
> >> > >
> >> > > the accessList also contains userPermission (this is set by the
> >> > > supperAdmin).//I'll come to supperAdmin at last
> >> > > here the userPermission level is handled in user basis.
> >> > > they are ; blocked< view < view&comment < modify <<<
supperAdmin
> >> > >
> >> > > A normal case eg. ;
> >> > > if openID1 is having userPermission as view and resourcePermission
> as
> >> > > view&comment
> >> > > he can only view that resource.
> >> > > even if this is the other-way around still he can only view!
> >> > >
> >> > > In a supperAdmin case eg. ;
> >> > > whatever the resourcePermission the supperAdmin can view modify and
> >> > delete
> >> > > pictures, comments and albums
> >> > >
> >> > >  As we are only starting i thought of implementing only with the
> >> > following
> >> > > access levels;
> >> > > resourcePermissions; blocked< modify
> >> > > userPermission; blocked< modify <<< supperAdmin
> >> > >
> >> > > The method  setUserPermission(User user, String userPermission);
> which
> >> is
> >> > > in the AccessManager
> >> > > is only accessible to the supperAdmin to set user permissions.
> >> > >
> >> > > to authenticate the supperAdmin there is two possible ways.
> >> > >
> >> > > 1. the OpenID of the supperAdmin will be in some property file hard
> >> coded
> >> > > at the deployment.
> >> > > and when the supperAdmin get authenticated as any other normal user,
> >> then
> >> > > the photArk will find out that the logged in user and the given
> >> > supperadmin
> >> > > OpenID is same and it will give the supperAdmin privileges to that
> >> user.
> >> > > 2. If you think authenticating supperAdmin through OpenID is not
> >> proper
> >> > and
> >> > > the supperAdmin should have more autority. we can have a different
> URL
> >> to
> >> > > supperAdmin login and protect that through  tomcat (like the present
> >> > > situation).
> >> > > please suggest which is the proper method of authentication for
> >> > > supperAdmin?
> >> > >
> >> > > the improved class diagram is in the PhotArk wiki
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/pages/editpage.action?pageId=20644183
> >> > >
> >> > > please give your suggestions and correct me if I have gone wrong.
> >> > >
> >> > > Regards
> >> > > Suho
> >> > >
> >> >
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message