Hi Thomas, If XWiki supports JAAS for authentication, it would be cool, solving also other issue that we had with authentication. I just found information on the internet that jetty supports JAAS. z.B. http://docs.codehaus.org/display/JETTY/JAAS Looking at this description, the integration appears to be reasonably easy and the LDAP Security Componente should be able to be rewritten as a JAAS LDAPLoginModule. You may not even need to do any changes to the datastructructures. Although, I havn't found yet how the mentioned chaining of authentication providers might work in Jetty. Could this still be a XWiki 1.0 feature? Gunter

...

...

"THOMAS, BRIAN M (ATTSI)" <[email protected]> 23.03.2007 19:59:44 >>>

Currently, XWiki allows only one method of authentication to be enabled. This means that using LDAP disables the normal XWiki users. This is an error in the architecture, and I vote for changing this. Instead of using only one authentication/rights mechanism, we should have a list. When trying to authenticate a user, all the registered authenticators should be used, until at least one correctly identifies the user. This should be better planned, so that in the future no other changes should be made. Sergiu You have just described JAAS. ------------------------------------------------------------------------------- Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -------------------------------------------------------------------------------

Gunter:

Hi Thomas,

For the record, it's Brian... won't go into that again, about having three "first" names, and international differences in name order... :> (no offense, of course; I'm well used to it...)

If XWiki supports JAAS for authentication, it would be cool, solving also other issue that we had with authentication. I just found information on the internet that jetty supports JAAS. z.B. http://docs.codehaus.org/display/JETTY/JAAS

Looking at this description, the integration appears to be reasonably easy and the LDAP Security Componente should be able to be rewritten as a JAAS LDAPLoginModule. You may not even need to do any changes to the datastructructures.

Although, I havn't found yet how the mentioned chaining of authentication providers might work in Jetty.

I began looking at incorporating JAAS into XWiki the first time I needed to incorporate a local enterprise authentication system. The provider of the authentication service had conveniently provided a JAAS implementation, so it was a natural choice. However, XWiki's access controls being as robust as they are made me loath to change out all three of the access-control services, because (among other things, such as my difficulty in getting the JAAS architecture through my rock head) it would entail scrapping a lot of XWiki's existing administrative tools. But, as the author of the comment to which you responded, I should have known that the use of multiple authentication modules that JAAS provides makes it possible to leave XWiki's default admin interfaces intact (primarily for providing local wiki administrative privileges that are most likely unknown - or should be - to an enterprise directory schema). I will note that on reading your original request, I felt a bit alarmed at the idea that there should be more than one authority granting access to your wiki. As a (former) Certified Information Systems Security Professional, I know that the enterprise security wonks may tend to get a bit edgy as well. But a necessary separation of concerns (organizational identity authentication versus local application administration) pretty much dictates this, and there really are not multiple sources of access authority. The wiki administrator, as the installer and maintainer of the LDAP-based user authentication discipline, is the final (and thus the only real) access-control authority; he merely grants directory-authenticated users access as a class on the basis of authenticated information provided by the directory service. Now I'll poke my nose into your security analysis, if it's not too obnoxious: If your need for retaining XWiki database IDs with passwords is limited to the administrative uses I mention above, and you are required to allow access only to people who are actually in your directory service, I'd suggest that you scrap the XWiki-local user authentication, and apply the needed authority via XWiki groups. This is what I've done. In other words, if all users must be employees, and all employees can be authenticated via your LDAP service, then let that be the only authentication mechanism. If some of those employees need privileges (such as admin access to the wiki or portions of it) that can't be determined or inferred from the directory schema, then use XWiki's group mechanism to assign them manually to groups to which the necessary rights are granted. This means, of course, that the default XWiki.Admin user can't log in, but any users who need that user's privileges can be added to XWiki.XWikiAdminGroup, which by design has the same privileges - yielding the added advantage that all audit trails of administrative activity in the wiki have an officially-authenticated identity instead of a generic one. It also nixes the use of the superadmin user, but that's still available to anyone with write access to the server files in emergencies. So pick your poison: JAAS it up for the coolness factor, or get it done quickly with no loss of security the simpler way (assuming that my guess as to your need for multiple authentication methods was correct). I apologize - sort of - for the length of this message; as one famous writer said, I didn't have time to make it shorter. "it is also said: Do not go to the Elves for advice, for they will say both yes and no." - J.R.R. Tolkien, The Fellowship of the Ring brain[sic]