RE: Antw: RE: [xwiki-users] LDAP -or- internal user management

Gunter: 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...) 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]