|
> my.domain\user has to be considered too in this case.
Is that used as a Kerberos V prinicipal name with Active Directory ? Is it possible to authenticate to Apache with mod_auth_kerb with such a principal name ? > Is that used as a Kerberos V prinicipal name with Active Directory ?
Yes for NT4 compatibility. "@domain" is used for Windows 2000 and later. > Is it possible to authenticate to Apache with mod_auth_kerb with such a principal name ? No idea... I use tomcat and JCIFS for NTLM authentication. Anyway, I assume Apache community takes care of backward compatibility  . Just attached "AppServerTrustedKerberosAuthServiceImpl-wikiname.patch" which is tested and works with Kerberos 5. It is slightly modified version of original patch, it handles situations where username contains dots. For wikiname conformity, "createUser(String user, XWikiContext context)" method of XWikiAuthServiceImpl has been altered to return wikiname String it already was determining for given username.
This patch also tackles situation when principal is in "domain\username" format - this was not tested. On xwiki users mailing list ( http://lists.xwiki.org/pipermail/users/2009-March/015403.html Second patch fixes only a minor typo in javadoc of AppServerTrustedAuthServiceImpl class. After applying this patch to xwiki-core-1.8-rc2 I keep getting the following error:
Wrapped Exception: java.lang.NoSuchMethodError: com.xpn.xwiki.user.impl.xwiki.AppServerTrustedKerber (rest omitted) I tried several JREs, as well as renaming the method into something different. I made sure that the changes were applied (line of actual error differs). There's nothing wrong with the code, as far as I can tell. May be somebody encountered this issue before or knows what can it be? If you applied patch I've attached, check that XWikiAuthServiceImpl method's "protected void createUser(String user, XWikiContext context) throws XWikiException" return type has been changed to "protected String createUser(String user, XWikiContext context) throws XWikiException" and that at appropriate places wikiname/user gets returned as value of method - this is important as principal username can be incompatible with xwiki, e.g. I've experienced issues if principal username contained dots. I've just used the fact that createUser method already performs username "normalization" to xwiki compatible form, so I just returned the result back to AppServerTrustedKerberosAuthServiceImpl.
This change of XWikiAuthServiceImpl's createUser method is the only change I've done to that class, although patch marks all lines as changed - I presume this is because of different formatter used in original and patched version (tabs, spaces, ...). Of course, this was the first item on my checklist.
javap output for AppServerTrustedKerberosAuthServiceImpl: 137: invokevirtual #105; //Method createUser:(Ljava/lang/String;Lcom/xpn/xwiki/XWikiContext;)Ljava/lang/String; and for corresponding XWikiAuthServiceImpl: protected java.lang.String createUser(java.lang.String, com.xpn.xwiki.XWikiContext) throws com.xpn.xwiki.XWikiException; as extracted from actually installed jar file. Attached new patches.
Patch for AppServerTrustedAuthServiceImpl is trivial javadoc typo fix. In previous kerberos patch, for XWikiAuthServiceImpl class all lines were marked as modified because of tabs/spaces. These patches work for me since XWiki 1.7.1, and even now with 1.8.1. Can someone else please test, too. I'd like to have this included in the XWiki asap, so I don't have to build xwiki-core with every new XWiki release. Hi Stevo,
I made the original hack/quickfix for Kerberos way back. I can see you have been quite busy > I'd like to have this included in the XWiki asap, so I don't have to build xwiki-core with every new XWiki release. I'm also pro inclusion in xwiki but I don't think you have to recompile xwiki every time a new release comes out. Just put the AppServerTrustedKerberosAuthServiceImpl.java in a seperate jar. I'm still using my original hack/qucikfix: 'AppServerTrustedKerberosAuthServiceImpl.java' in a seperate jar which I place in the /WEB-INF of xwiki. Separate jar would be OK, hadn't I modified XWikiAuthServiceImpl class too - it's createUser returns xwiki valid username.
Thus, one has to, not to build entire jar but rather, in xwiki-core.jar for given release, replace/include changed/new class files. To get class files one has to apply patch to given release sources, and compile the project. Sorry, I hadn't noticed you also modified XWikiAuthServiceImpl .
Maybe we can then push for inclusion of the patched XWikiAuthServiceImpl first, separately of the Kerberos specific code ? I'll look at the patch today.
Alex, I just had same issue when applying patch to xwiki 1.8.2, Eclipse was complaining about assigning void (previous return type of createUser) to a String. With Eclipse 3.4.2 and Subversive 0.7.8 plug-in, applying patch to XWikiAuthServiceImpl just didn't trigger compiling of the class. Triggering compilation did the work for me.
Sergiu, did you have time to look at xwiki-core-AppServerTrustedKerberosAuthServiceImpl.patch? It works with 1.8.2 too. Are there any chances to have that patch applied and included in 1.9 release? No, I didn't look at it yet. Scheduling for review...
Sergiu, tell us if you want to commit in 1.9RC2 but it needs to be done quickly if that's the case
Attaching updated patches to latest xwiki release (2.1.1, r26232). Issue is trivial yet more than a year old...
|
|||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Minor
Single Sign on HTTP Negiotiate login
. Unfortunately I haven't had time (yet) to give your patch a spin.
my.domain\user has to be considered too in this case.