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 >
