Old discussion (refa cto ddr eventually)#

A new start for this page, as I'm slowly being reactivated on the subject thanks to custom needs and Mortena's insistence ;). Look at version 24 for deleted discussion. I choose to avoid external frameworks for now; they would be a major rebuild, and that discussion belongs elsewhere.

Please comment in the Feedback[1] section; I want to try to keep the requirements and implementation section fairly coherent, to actually summarize what we intend to do.

--ebu


Requirements#

We need a system for authenticating users that

  • is container independent
  • allows pluggable access classes
  • stores auth info with the session
  • is visible in the gui as an includable form; submit authenticates the user and returns to the same page. (This form could be included in a side bar, or presented as a front page to prevent unauthenticated access entirely.)

All this system needs to do is get a user name and password, and compare them to a stored set of uid/passwd. JSPWiki access control happens elsewhere.

Pluggability allows us to create a default implementation (e.g. something that reads a WikiPage) and custom ones (SQL, LDAP, text file, etc.).


Implementation#

As far as I can tell, the first two requirements rule out FORM-based authentication; Tomcat (4) ties that in with its Realm classes, and independence flies out of the window. My proposition is as follows:

  • A simple LoginForm.jsp file to include in sidebar (or front page, in custom wiki installations)
  • Submit on LoginForm posts to a Login servlet (or JSP page), which calls an Authenticator (as configured in jspwiki.properties).
  • The Authenticator implementation sucks up information somehow, creates a WikiUserPrincipal (WUP), and attaches it to the session. (I would expect the WUP to contain the user ID, a flag for successful authentication, and the user's password, obfuscated. Other information - user preferences, etc. - could be added, probably in Map-like fashion.)
  • The LoginForm also includes the WikiPage submit was clicked on, and Login redirects back to that page. Subsequent invocations of LoginForm.jsp notice the WUP and display a logout button instead of the login form.
  • The WikiEngine should provide the WUP to any subsystems (e.g. WikiPlugins) upon request.

So, new classes and files added to JSPWiki:

Note: as proposed, a WikiPageAuthenticator without any access control leaves the system open to mischief. The authentication page should definitely be restricted with access control measures. ;)


Feedback#

Any objections? Encouragement? Flat-out denial? =) --ebu

  • Q: Why should the WikiUserPrincipal store the user's password?
    • A: When using JSPWiki as an interface to your custom information system, you may need to identify users to external systems. As long as we don't have access control, we need to be able to authenticate internally - and even when we do, external systems may not share access permissions with JSPWiki.
  • Perfect page...This page is clear and states exactly what is needed to implement Authentication. If you need any help implementing it, just say the word...--Mortena
  • There is only one problem of textbased passwords that can be seen by many other persons: The password might be the same for other sites. This is maybe something that we must consider, as the users probably won't do it.

Q: Any idea about read passwords from /etc/password or /etc/shadow?


Other info#

ebu has written a Tomcat 4 compatible Realm for accessing our custom user DB. It will not be useful to anyone as such, but if you haven't written a Tomcat Realm before, might speed up your own custom solution. Email ebu if you need more info.


I'll dump this here even though it goes across JSPWikiAuthentication and JSPWikiAuthorization.

We'll need a sort-of-a-triplicate method of authentication:

  1. User has not authenticated in any way - this is a "Guest" role.
  2. Current way - user just types in name in UserPreferences. He has a name, but he is not authenticated. So, he is still in "Guest" role. The user name is persistent and stored in the cookie.
  3. User authenticates via a password - he now has a name AND he is authenticated. He gets whichever rights are available to him, and is attached to different rols. The user login information is stored inside the HttpSession.

All of these have to be available concurrently, with the option of turning any of these off. It's required to provide an "admin" account for public wiki sites, for example.

-- JanneJalkanen

  1. Authentication is verification that the user is who they claim to be.
  2. Authorization is determination of what the user is allowed to do.
Once a user is authenticated the user is mapped to a set of roles. The roles are then mapped to a set of actions allowed for the roles.

For example, a user in the "guest" role might be allowed to view pages but not edit them. There might also be an "author" role that allows users to create, edit, and view pages and an "editor" role that allows the user to edit and view but not create pages. An "admin" role might be used to delete pages and perform other maintenence.

When a user is authenticated, the user is also mapped to a set of roles that can be used for authorization. The J2EE security model can handle this but it often leaves much to be desired. On the other hand servl;et security is standardized whereas application based security is often difficult to integrate with other systems and is difficult to chnage as requirements change.

I suggest a security plugin capability that comes with a default plugin supporting the servlet security model but also supporting tags for supporting an application based model. The servlet security model is not Tomcat specific. The default plug-in would use request.getRemoteUser() and request.isUserInRole() to determine if the user was authenticated and authorized for a particular task.

-- JTBell

NB: This discussion is obsolete already; the security model from JAAS has already been adopted for 2.3...

-- JanneJalkanen

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-18) was last changed on 26-Oct-2006 10:39 by JanneJalkanen