Antonio: This response is probably not much use, but it might be, and besides I enjoy showing off my brilliance... Because JForum is a J2EE implementation of phpbb, moving to it will probably be less difficult for users (and maybe administrators as well). We have installed JForum (and Roller for blogging) on the same appserver with our XWiki instance. The integration of the three was limited to placing links to them in XWiki's viewheader menu. This has (I think) one small advantage over phpbb since, as J2EE servlets, all could share the appserver and its session, so that logging in to one is logging in to all. However, all three used separate user databases and hence separate registration despite being on the same host and being skinned to look mostly like a single application. This resulted in a lot of user confusion, because it was not clear that they needed to register individually on each of the three applications - I received numerous calls from users who didn't understand this. If you use XWiki's LDAP plugin (and your forum tool has an equivalent option) or a similar mechanism to what we are now doing - which is a servlet filter that digests cookies set by our SSO server and automatically registers users in each one - this will all go much more smoothly, of course. The filter is simple to deploy but, with very little standardization in J2EE security practices (none that I know of in the user lifecycle space) it can be challenging to adapt to each servlet's specific registration needs. In my case, the generic filter was finished in about three days (counting the time it took to learn the relevant Servlet API parts) but the adapter class that applied it to XWiki took more than two weeks. This was just a little above the average: one JSP developer took my jarfile one morning (while the filter was still in development), informed me of a bug around noon, waited for me to fix the bug and deliver the new jarfile, and had it working with his app before he left for the day; the guy working with Roller took about three weeks (though, to be fair, he was also fighting the vagaries of a new release of Roller with a very different configuration of the ACEGI security package). JForum took about the same as XWiki, mostly because of having to interact with other servlet filters in its deployment. brain[sic] ------------------------------ *From:* Antonio Goncalves [mailto:antonio.mailing@gmail.com] *Sent:* Tuesday, April 17, 2007 2:37 PM *To:* xwiki-users(a)objectweb.org *Subject:* [xwiki-users] Which forum to use with XWiki Hi, With my XWiki I need a forum so people can exchange information on various topics. I'm installed phpbb but I was wondering if there was any "better" integration between another product (JForum or JavaBB). Has anybody installed such product ? Any feedback ? Thanks, Antonio -- You receive this message as a subscriber of the xwiki-users(a)objectweb.orgmailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Thanks for the information. I think that like Paul I'm going first to install and use JForum (and give up phpBB), and then set it up so SSO is used between both applications. Antonio 2007/4/19, THOMAS, BRIAN M (ATTSI) <bt0008(a)att.com>om>: > > Antonio: > > This response is probably not much use, but it might be, and besides > I enjoy showing off my brilliance... > > Because JForum is a J2EE implementation of phpbb, moving to it will > probably be less difficult for users (and maybe administrators as

> We > have installed JForum (and Roller for blogging) on the same appserver

> with our XWiki instance. The integration of the three was limited to

> placing links to them in XWiki's viewheader menu. This has (I think)

> one small advantage over phpbb since, as J2EE servlets, all could > share the appserver and its session, so that logging in to one is > logging in to all. > > However, all three used separate user databases and hence separate > registration despite being on the same host and being skinned to look

> mostly like a single application. This resulted in a lot of user > confusion, because it was not clear that they needed to register > individually on each of the three applications - I received numerous > calls from users who didn't understand this. > > If you use XWiki's LDAP plugin (and your forum tool has an equivalent > option) or a similar mechanism to what we are now doing - which is a > servlet filter that digests cookies set by our SSO server and > automatically registers users in each one - this will all go much > more smoothly, of course. > > The filter is simple to deploy but, with very little standardization > in J2EE security practices (none that I know of in the user lifecycle

> space) it can be challenging to adapt to each servlet's specific > registration needs. > In my case, the generic filter was finished in about three days > (counting the time it took to learn the relevant Servlet API parts) > but the adapter class that applied it to XWiki took more than two > weeks. This was just a little above the average: one JSP developer > took my jarfile one morning (while the filter was still in > development), informed me of a bug around noon, waited for me to fix > the bug and deliver the new jarfile, and had it working with his app > before he left for the day; the guy working with Roller took about > three weeks (though, to be fair, he was also fighting the vagaries of

> a new release of Roller with a very different configuration of the > ACEGI security package). JForum took about the same as XWiki, mostly

-- You receive this message as a subscriber of the xwiki-users(a)objectweb.org mailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

-----Original Message----- From: Thomas Krämer [mailto:tk@ontopica.de] Sent: Tuesday, May 29, 2007 6:43 AM To: xwiki-users(a)objectweb.org Subject: Re: [xwiki-users] Which forum to use with XWiki hey shiva, i finished exactly the scenario you depicted yesterday: the many advantages of xwiki (as blog and wiki engine) combined with an advanced forum, that takes into account the discoursive nature of knowledge development in enterprises as well as in non profit contexts. in brief, there are two major issues: authentication and authorisation. fortunately the xwiki developpers have done a good job in providing a configurable mechanism to switch the authentication class (see xwiki.cfg or the respective section in the admin guide) You implement the XWikiAuthService and probably the XWikiAuthenticator interfaces and at the next login, credentials are verified you defined in these classes. i do an (layered) access to an existing application (the forum part of your scenario; it's not necessarily the better user management, it simply was there first). a little trickier is the second issue, authorisation. i decided to let the quite mature user / group / right management systems of both apps as untouched as possible, but enable one of them to rule over the other. sergiu uttered the idea of a REST approach, which i turned into some kind of remote control for the xwiki user management. so, whenever my forum admin want to have a new group, a new group is created in both systems, a space with the id [groupname] is created where only grup member have edit rights etc. i attached an outline of that class. that is, however, not the only way to do what you want, and possibly not even the most appropriate. Yours Thomas shivshan schrieb: sometime. going first to it up so SSO and besides to it will administrators as well). the three was menu. This separate I received which is a standardization API parts) developer for me to fix with his app took about vagaries as XWiki, filters in information on if there was Has anybody ---------------------------------------------------------------------- xwiki-users(a)objectweb.org mailing list. -- ontopica Thomas Krämer Krämer&Okpue GbR Kurfürstenstr. 66 53115 Bonn Fon +49 228 - 180 99 737 Fax +49 228 - 242 78 60 Email tk(a)ontopica.de

-----Original Message----- From: Esbach, Brandon [mailto:Esbachb@tycoelectronics.com] Sent: Tuesday, May 29, 2007 8:18 AM To: xwiki-users(a)objectweb.org Subject: RE: [xwiki-users] Which forum to use with XWiki Now that sounds like an interesting solution.. Any info on setting that up would be welcome ;). -----Original Message----- From: THOMAS, BRIAN M (ATTSI) [mailto:bt0008@att.com] Sent: 29 May 2007 14:09 To: xwiki-users(a)objectweb.org Subject: RE: [xwiki-users] Which forum to use with XWiki I have also implemented SSO with XWiki, and also agreed that the rights management of XWiki was very robust. Further, I didn't want to take away (or re-implement) the XWiki rights administration tools, because while authentication (from an enterprise standpoint) is a matter for the corporate security authorities, authorization to wiki resources is a matter for the wiki admins. My solution, which has since been applied to many other J2EE applications in our enterprise, is to use a servlet filter to intercept the requests, check out the SSO-supplied cookies, and redirect to the SSO service if not found, without having to implement our own XWiki authentication service. Actually, two instances of the filter were created: one optioned to redirect if proper authentication cookies were not found, and one that simply passed through in that event. In this way, we could get and use the identity of those who were authenticated without requiring authentication to paths that didn't require it. Indeed, because XWiki redirects any unauthenticated request for an action requiring authentication to the login page, the authentication-required version only needed to be mapped to the /login/* url-pattern. It also handled the registration of any user who hadn't been seen before, and mapped attributes provided by the SSO cookies to XWiki groups, through an XWiki document which associated a cookie field and a regular expression with a group, so that if the specified cookie field matched the regular expression, the user was added to the group. In this way a proper separation of duties was maintained between the enterprise SSO system and the local administration which it informed. Equally important for me, I didn't need to modify any XWiki code, so that migrating the solution to 1.0 required only making the same modifications to the user profile document that had been made to the 0.9.840 instances and importing the group mapping page. brain[sic] combined with nature of providing a XWikiAuthenticator you defined application better user one of them into some group is possibly knowledgebase. session, so that skinned to a lot of all go much servlet's more than two configuration of ----------------------------------------------------------------------

-----Original Message----- From: Thomas Krämer [mailto:tk@ontopica.de] Sent: Tuesday, May 29, 2007 8:31 AM To: xwiki-users(a)objectweb.org Subject: Re: [xwiki-users] Which forum to use with XWiki Hello that sounds like a very clean solution. A couple of days ago i tried to start a discussion about the points you mentionned: separtion of concerns / id management / wiki access management. currently, the "SSO" is achieved, by letting one of two applications (the forum) handle the credentials. Towards a less coupled and more flexible (a "real") SSO, i /we 'd need to choose from varios SSO solutions and adapt xwiki in a way as you did, for example. Did you use an os sso, Thomas? I thought of yale cas, but there are interesting idms like + http://esoeproject.org/ + http://www.josso.org/ + http://www.acegisecurity.org/ and of course http://jguard.net/ Vincent remarked, that this could possibly fit into the XEM project, that recently started. I think it would be a good idea to agree on an SSO / idms and make a joint implementation effort, if there are more people, that have xwiki plus x. What's your opinion? Regards Thomas THOMAS, BRIAN M (ATTSI) schrieb: that the rights management of XWiki was very robust. Further, I didn't want to take away (or re-implement) the XWiki rights administration tools, because while authentication (from an enterprise standpoint) is a matter for the corporate security authorities, authorization to wiki resources is a matter for the wiki admins. J2EE applications in our enterprise, is to use a servlet filter to intercept the requests, check out the SSO-supplied cookies, and redirect to the SSO service if not found, without having to implement our own XWiki authentication service. Actually, two instances of the filter were created: one optioned to redirect if proper authentication cookies were not found, and one that simply passed through in that event. In this way, we could get and use the identity of those who were authenticated without requiring authentication to paths that didn't require it. Indeed, because XWiki redirects any unauthenticated request for an action requiring authentication to the login page, the authentication-required version only needed to be mapped to the /login/* url-pattern. been seen before, and mapped attributes provided by the SSO cookies to XWiki groups, through an XWiki document which associated a cookie field and a regular expression with a group, so that if the specified cookie field matched the regular expression, the user was added to the group. In this way a proper separation of duties was maintained between the enterprise SSO system and the local administration which it informed. Equally important for me, I didn't need to modify any XWiki code, so that migrating the solution to 1.0 required only making the same modifications to the user profile document that had been made to the 0.9.840 instances and importing the group mapping page. combined with nature of providing a credentials are access to an one of them into some new group is is created and possibly knowledgebase. session, so that skinned to a lot of all go much servlet's more than two configuration of --------------------------------------------------------------------- ---------------------------------------------------------------------- xwiki-users(a)objectweb.org mailing list. -- ontopica Thomas Krämer Krämer&Okpue GbR Kurfürstenstr. 66 53115 Bonn Fon +49 228 - 180 99 737 Fax +49 228 - 242 78 60 Email tk(a)ontopica.de