5 Mar
2009
5 Mar
'09
2:51 p.m.
Just found what was the problem. Importing XAR, as Import-Export page of
Admin Guide documents, alters rights: "At this stage your rights might have
been changed as the import may have imported different rights. You may need
to log out and log in again."
Problem is that log out and then log in solution for some reason doesn't
work for user previously authenticated/created over kerberos. I believe this
is because user is not being updated/synchronized after it has been created
using AppServerTrustedKerberosAuthServiceImpl.
My solution, with clean/fresh xwiki (database), was to access xwiki first
with kerberos disabled (either in xwiki configuration, or just temporarly
adjust browser, in my case firefox, not to trust xwiki service), then import
initial content as not-logged in user, then reenable kerberos, and finally
try accessing xwiki - upon that user will be created and it will have
appropriate access rights.
Not sure how, but I believe AppServerTrustedKerberosAuthServiceImpl should
be altered to better handle this situation.
Other issue with "xwiki.authentication.createuser=ldap" not
binding/searching well for user details is still present - would be nice to
have it fixed.
Mentioning of authkerb.jar in Authentication page of Admin Guide should be
removed, it's not needed and might be misleading.
Regards,
Stevo.
2009/3/5 Stevo Slavić <sslavic(a)gmail.com>
Same happens with
AppServerTrustedKerberosAuthServiceImpl - user gets
created (I've checked in xwikidoc table), "edit" right is passed as
parameter to createEmptyUser method (not sure where to check in the db if
right has actually been applied), but still all the pages including main
home page report error "You are not allowed to view this document or perform
this action.". Maybe it has to do with fact that user is first created
(automatically just by visiting) and only after that I import initial
content (xwiki-enterprise-wiki-1.8-rc-1.xar).
Authentication page in admin guide mentions authkerb.jar - this jar is
nowhere to be found, but also seems not to be required.
One other issue is if instead "empty" I configure
"xwiki.authentication.createuser=ldap", when obtaining user details plugin
wrongly tries to bind only with principal/username - binding with admin
account then search should be tried as well, just like
XWikiLDAPAuthServiceImpl seems to work/fallback to.
If just "empty" user would work I'd be satisfied. I've checked out
source
but can not find what is wrong. Btw, source code doesn't look to be in good
shape - XWiki class is huge, XWikiLDAPAuthServiceImpl has some important
TODOs, XWikiRightServiceImpl's checkRight and hasAccessLevel methods are
very long, lots of non externalized messages, magic values, ...
Any thoughts on where to look for solution to this access rights issue
would be appreciated.
Thanks in advance!
Regards,
Stevo.
On Thu, Feb 26, 2009 at 5:21 PM, Stevo Slavić <sslavic(a)gmail.com> wrote:
Hello all,
I'm trying to configure Kerberos SSO using
AppServerTrustedAuthServiceImpl. I'm using latest xwiki, 1.8 rc 1 and to the
contrary of what Admin Guide for Authentication states, this class is
included in xwiki-core module. Nevertheless, I've configured application
server well and set AppServerTrustedAuthServiceImpl to be used. Problem is
that user authorization checks fail.
In debug log I saw that user creation was started but auth_createuser
context param was empty/null and thus not equal to string "empty" which
createUser of XWikiAuthServiceImpl expects, so user wouldn't actually get
created and thus when XWikiRightServiceImpl. To set auth_createuser
parameter to "empty" I've adjusted xwiki.cfg by adding
xwiki.authentication.createuser=empty. If this is what really has to be
done, it would be good that Admin Guide gets updated with this information.
After setting createuser to "empty", debug log changed but just a little
bit (see attached log archive). Now it seems that user is being created but
it still has no access rights. Does someone have any ideas how to configure
this to work? Thanks in advance!
Regards,
Stevo.