| At line 1 changed 3 lines |
| ''Authentication'' is the process of logging in, and making sure that the user actually is who he says he is. |
| ''Authorization'', or access control, defines the rights and permissions of users, be they unauthenticated guests or known and authenticated individuals. |
| While the two are separate problems from an architecture perspective, an adminitrator usually considers them jointly. Thus, this combined status and instruction page. |
| Obsolete. Check out the [Security2.3Howto]. |
| At line 5 changed one line |
| !Current status: early alpha. Only available in CVS. |
| The article ["Introduction to JSPWiki"|http://linuxgazette.net/108/youngman.html] in Linux Gazette has a link to this page, so it should be preserved with links to the current security/authentication system. |
| At line 7 removed 2 lines |
| JSPWiki version 2.1.51 is slowly acquiring auth capabilities. |
| Under development by [Janne|Janne Jalkanen]. Syntax may still change. |
| At line 10 removed 2 lines |
| User authentication and authorization works; groups don't. Only the three default groups ''Guest'', ''NamedGuest'', and ''KnownPerson'' are currently usable. |
|
| At line 14 changed 68 lines |
| !!Setting up user authentication |
|
| Add the following properties to ''jspwiki.properties'': |
| {{{ |
| jspwiki.authenticator = FileAuthenticator |
| jspwiki.fileAuthenticator.fileName = /tmp/passwords.txt |
| }}} |
|
| Edit the password file: |
| {{{ |
| # The format is simply username = password |
| # No encryption is used currently. |
| # Comments are allowed; prepend with hash. |
| ebu = foobar |
| ubi = frobozz |
| }}} |
|
| Restart the container, and access the main page. If you use the default [template|JSP Wiki Templates], a small login box should appear in the left margin. Enter the username in the upper box and the password in the lower, and click on login. If you see the friendly greeting, you have authenticated successfully. |
|
| !Developers: |
|
| ''~FileAuthenticator'' is a fairly simple class, ''com.ecyrd.jspwiki.auth.modules.~FileAuthenticator''. You write your own class to implement ''com.ecyrd.jspwiki.auth.~WikiAuthenticator'', make sure the webapp can find the class, and use the full class name for the ''jspwiki.authenticator'' property to do your own, custom authentication. |
|
| --- |
| !!About Groups |
|
| Group support is not finished at this time. Three system groups are defined: |
| * anyone accessing the wiki belongs to group ''Guest'' |
| * anyone who has set their name on the user preferences page belongs to group ''NamedGuest'' |
| * anyone who has been authenticated belongs to group ''KnownPerson'' |
|
| ---- |
| !!Authorization |
|
| !Access Rules |
|
| Plugin-like entries on a page define the access level of users. The following examples illustrate the syntax: |
|
| A publicly viewable page (since everyone belongs to group ''Guest'', editable only by users ebu and ubi: |
| {{{ |
| [[{ALLOW view Guest}] |
| [[{DENY edit Guest}] |
| [[{ALLOW edit ebu, ubi}] |
| }}} |
|
| A page viewable by ebu and ubi only, editable by ebu only: |
| {{{ |
| [[{DENY view Guest}] |
| [[{ALLOW view ebu, ubi}] |
| [[{DENY edit Guest}] |
| [[{ALLOW edit ebu}] |
| }}} |
|
| As can be seen from the parameters, both usernames and group names can be specified in access rules. (We just can't specify new groups quite yet.) Note that ''edit'' does not imply ''view''. |
|
|
| !Default Access Rules |
|
| Theoretically, creating a page named ''DefaultPermissions'' and placing a set of access rules on it should make those rules apply to all pages. Page-specific access rules should replace the defaults, if present. ''However'', the default system does not seem to work properly, and is liable to change (at least into a more configurable form). |
|
|
| ---- |
|
| Old discussion: [Requirements for JSPWiki Authentication] |
|
| ---- |
|
| [Category Development] - to be moved to Documentation once auth* is ready. |
| I was surprised to find this page deleted. I understand that the new security model is far better than this one; however, so long as v2.2.33 remains your "Current stable release" and 2.3.x / 2.4.x remain betas, you should keep the documentation for 2.2.33 available. All 3 of your security pages were properly marked at the top with the version numbers they applied to and I think that was the right way to do it. (I managed to diff version 79 and 80, grab the mark-up and copy it my Wiki (intranet, sorry) so I'm OK but for other |
