OpenWGA has a pluggable authentication mechanism which is capable of using many authentication sources. In order to do anything useful with your OpenWGA server the authentication has to be setup so any author can login and work with content.
The easiest way to do is via the server setup assistant which automatically comes up after installation when accessing the servers root URL or admin client under "/admin". This automatically setups an XML-file based authentication and already allows you to create a user that is manager on all web applications to come.
Alternatively you can setup authentication manually. There are two, relatively easy, options for now:
- Use the plugin IG User Management from the plugin store (since OpenWGA 6). Quite powerful and in use on many productive websites. Not trivial but still easy to setup.
- Create and use an Authentication-XML-File manually. Trivial to setup but is only really useful if you setup a small number of users/group once and then very change them at very rare occasions.
See chapter Authentication from Concepts and Features if you want to know details how this works in OpenWGA.
1 a) Using plugin "IG User Management"
The IG user management plugin (previously "OpenWGA User Management 2") provides the design for an application to define user logins and groups via a web GUI. You can install this plugin, create a web app using it as design provider and then use this app to define your users and groups.
There is a separate documentation for this plugin, providing a guide how to install and setup it here: IG User Management.
Use the info there to create a new web app using this plugin as design provider. If you have created multiple OpenWGA domains, ensure that the app will be part of the domain for which you want the authentication to be effective. (If you do not yet know what OpenWGA domains are, nevermind ;-)
We will define users and groups later in step 3.
1 b) Using the XML-Authentication-File
See this document from the OpenWGA documentation library which describes the XML-File-Syntax used to define logins. Create such a file and fill it with the logins that should be valid for your applications.
Then you should store the file on the file system of your OpenWGA server. It is recommended to store it to the configuration directory of your OpenWGA server runtime. You can find out the location of the OpenWGA configuration directory on the OpenWGA admin client:
- Choose "Runtime" from the main menu, then "Status" from the submenu
- On Tab "Operating System" you see the entry "Configuration file". The configuration directory is the directory that this file is contained in.
2. Let domain "default" use the respective auth source
The configuration point for authentication in OpenWGA is the "domain". Each OpenWGA application belongs to a domain and will use the authentication configured for it. Every server has a default domain "default" preconfigured which all apps belong to until the admin configures something different.
- In OpenWGA admin client choose "Domains" from the main menu
- Click domain "default" which is available automatically (or of course any other domain that you want to setup authentication for
- Click "Edit" to edit the domain settings
- Check the box "This domain uses authentication"
- For plugin "IG User Management"
- On "Authentication source" choose "Content Store"
- On "Authentication content store" choose your created app
- Should look like this
- For XML-Authentication-File
- On "Authentication source" choose "XML Authentication File"
- On "Authentication file path" specify the path to your XML file on the servers file system. If you stored it to the configuration directory simply specifyng its name without path should do.
- Should look like this (file path may vary of course):
- Click "Save" to save the domain settings
This will make the plugin/your XML-File the active authentication source for all OpenWGA applications of this domain.
3. Define users and groups
If you use the XML file you might already have defined users and groups in there. You can do this at step 1. or now. Just edit the file using the documented syntax and your changes become instantly effective.
If you use the plugin then now is the time to actually do this. We could not do this before because as your new users app is both, an app defining logins AND an app that needs login definitions to authenticate users, we could not access the apps GUI before authentication was properly setup on the domain.
Now access the users app using its root URL "/databaseKey", where database key is the key you defined when creating the app. Login with the default user login "admin" password "wga" of the user management plugin.
You should see this UI:
We think it is pretty self-explanatory. Use the menu on the left to navigate to the users or groups list, create and edit users and groups there. Remember to change the password of the "admin" user before your system goes productive!
However, as already said, there is a separate documentation available explaining some more things in detail.
4. Use login names in the ACL of applications
Now you can specify individual access rights to your applications based on the users that are defined in your authentication file or content store:
- In OpenWGA admin client choose "Web Applications" on the main menu. Choose an application which belongs to the domain just configured and where you want to modify access rights.
- Click tab "ACL". Here you can specify individual access rights to individual people. Details about this functionality can be found on this document from the OpenWGA documentation library. However here are the basics:
- On "Default entries" you can specify basic access rights for anonymous users and for "not specified users", which are all users that can successfully login but are not treated by any custom entries.
- On "Custom entries" you can configure individual entries for individual persons and groups. Click button "New entry" to add an entry. Specify the name of a group or person from your auth source (either the fully distinguished name or an alias). Then define an access level for the group or person. Click "save" to store the entry.
- On "Roles" you can define roles for your application and assign them to the existing custom entries. Roles as such are not attributed with any predefined access rights but may be used by the application like an "application-specific group" which has special application-dependent rights.
Here is how the ACL of a typical application - like a blog in this case - may look like. It offers anonymous users "Reader" access (otherwise only logged in users would be able to see any blog entries). Everyone who is logged in is an "Editor", which means they can post blog entries. A special group "managers" defined in the auth source is given "Manager" access which means they can create/manage/delete individual blogs.