On 20 May 2010 11:22, Avdhesh Yadav <[email protected]> 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 [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 < > [email protected]> 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 <[email protected]> > > wrote: > > > > > > > > > > > On 2 May 2010 00:36, Avdhesh <[email protected]> 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 > > > > > >
