29 May
2007
29 May
'07
4:39 p.m.
Having very little time, I'll have to give it to you in bits, I think, relying on your
ability to find out and fill in details for yourself.
First and foremost, you need to be familiar with the Servlet API if you're not
already. Sun has a very good PDF document on the whole thing (java.sun.com/ something or
other; sorry, don't have the link handy).
The servlet filter is an implementation of javax.servlet.Filter. The doFilter method is
passed the request, response, and the filter chain. From the request you can get the
cookies, the servlet context, and the session, where you can squirrel away any data that
need to persist throughout the session; the response is what you need in order to
redirect; and the filter chain is what you use to pass an accepted request down the
chain.
All of the application-specific stuff is in a custom implementation of an interface, whose
most important method returns an HttpServletRequestWrapper made from the original request.
For XWiki, the wrapper must implement HttpServletRequestWrapper.getUserPrincipal() to
return a java.lang.Principal implementation whose getName() method returns the XWiki
username (which, unfortunately, is not the same as the user's login name but the name
of the user's XWiki profile, "XWiki."+logname). This Principal object must
also be stored in the HttpSession under the key named by
org.securityfilter.filter.SecurityRequestWrapper.PRINCIPAL_SESSION_KEY in order to
complete the deception that keeps XWiki from any clue that its own authentication scheme
has not been successfully negotiated.
I think there are better ways to do it, but I simply modified the XWiki.Login template to
redirect to the URL given by the xredirect parameter if present, or the default page
(Main.WebHome) if not. Since (ironically enough) the filter will never allow an
unauthenticated request to reach that path, this will be appropriate.
To do the user pre-registration and group membership parts, you have to get a handle on
the XWiki instance and a workable context. I used com.xpn.xwiki.web.ViewEditAction as an
example, and called the static method XWiki.getXWiki(context), which required a call to
Utils.prepareContext with a newly-created XWikiContext and a bunch of stuff that you have
to create.
Group memberships are a pain, because the requirements for saving objects with a document
were not (to me) intuitive at all; the only way I was able to figure it out was by looking
at the sources for XWikiService.actionObjectRemove.
You should be able to get started now; probably should mail questions etc. directly to me,
and maybe we can summarize to the list or to xwiki.org.
brain[sic]
-----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]
session, so that
skinned to
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 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:
knowledgebase.
Hi
I have been thinking of integrating XWiki into a portal for
sometime.
> The ideal scenario would be to have a wiki, forum and blog all
> integrated within the Portal, which is the company's Am
debating whether to use SSO for different standalone apps like
XWiki, JForum etc or take a plunge into Exo/JBoss.
Any inputs/experiences would be greatly appreciated.
Thanks
Shiva
Antonio Goncalves wrote:
> 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 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 >>
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 >>> 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 >>
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 >>
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 >>
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 >>
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
>
>
--
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
--
--
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
--
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