ocPortal Tutorial: Integrating ocPortal into a network via HTTP authentication

Written by Chris Graham, ocProducts

Authentication via HTTP

Authentication is required to even reach the web application

On a normal ocPortal installation (an ocPortal powered website), whatever forum system is being used contains member details in it's database; ocPortal authenticates to this, using custom forum drivers to tackle the differing systems. For users to login to these, they need to enter their details, in either the forum, or ocPortal, and then ocPortal can maintain the login using login cookies and/or sessions (propagated by URL or session cookie s).

Sometimes, however, for additional security and/or integration reasons, it is desirable to be able to login via the HTTP authentication screen present in web browsers. ocPortal supports this form of login (if using the OCF system), in a platform independent way: therefore it may be accomplished by any web server scheme, such as Apache .htaccess, or IIS account-integrated security.

Table of contents

ocPortal Tutorial: Integrating ocPortal into a network via HTTP authentication

HTTP authentication in ocPortal

Security Tip

Note that when using HTTP authentication, the user-name and passwords are available in plain text to any PHP script that can exist in the same domain as the ocPortal installation: although you would normally trust those with the ability to write PHP scripts on your domain, make sure you consider this ability for them to read anyone's password.

If enabled, any new HTTP-Auth user ocPortal sees, is added to ocPortal, after ocPortal collects some additional details for that user (including the desired user-name to connect to the HTTP-auth user-name, and their e-mail address). Note that by the time ocPortal sees a page view, the http-authentication scheme has already guaranteed that it is by a real, authenticated user. Once the activation information has been collected, no form of additional login is ever required for any zone controlled by HTTP authentication (although it is possible to override the HTTP authentication with a manual login if desired, for example, by staff).

Note: Account completion is not considered the same as joining. Members will by put into all default usergroups, but the ocPortal feature for giving members a choice of usergroup is not supported (that feature is only for members that join manually, as it requires a two-form join process, and we designed HTTP-auth profile completion to just by one-form).

Instructions

Enabling HTTP-authentication recognition in ocPortal

You will likely want to disable joining ocPortal, so only HTTP-auth members may use it

In order to use HTTP authentication, it must first be enabled. It is likely you will also wish to deny permission to access the 'join' page (in the Welcome zone); this isn't strictly necessary for any kind of security reason because only an HTTP-auth user may access a restricted area of ocPortal by nature of the HTTP-auth itself (as it runs 'above' ocPortal in terms of system layering), but it is cleaner to avoid problems that may result in users creating secondary accounts.

Unlike ocPortal LDAP integration, HTTP-auth members do not inherit any usergroups from the HTTP authentication system, as HTTP authentication does not define any such membership. Therefore you have full control over what usergroups members are of, once their account has become known to ocPortal (when it has been activated by a user authenticating under the associated HTTP-auth user-name). You cannot change the password of an HTTP-auth user, because ocPortal does not consider such a bound account to have a password. You also cannot log-out from an HTTP-auth user, although you can forcibly login as a normal user to create an override. HTTP-auth users may be edited as necessary (by editing their bound profiles), including banning them if desired.

Upon first login, members must complete their profile

The default ocPortal install is intentionally split into different zones, such that the Welcome Zone is minimalistic, and most site functionality is contained in the 'site' zone. This allows you to use the Welcome Zone (located at your base-URL) as a non-logged-in 'welcome' page available to anyone, whilst restricting all other zones (and possibly the 'uploads' directory or subdirectories there-of) with HTTP-authentication.
ocPortal does not need any special configuration itself, and will simply bind to an HTTP-auth user only when it sees one is being used and when it sees that there is no normal-user override (i.e. you don't have a manual ocPortal login in addition to HTTP-authentication).
When defining access rules on Apache you will need to define most of the HTTP-auth settings (i.e. define the security zone) in the main .htaccess file, and then place the actual restrictions (e.g. require valid-user) on the files placed within individual zones (and the 'data' directory also – it is key this is given it too, or parts of ocPortal will not function correctly due to inconsistent login state across frames). You must not define the full set of security settings separately for each zone because it will make the web browser treat each zone and the 'data' directory as having separate logins, causing a lot of repeated requests for re-authentication.
One further note about the Welcome Zone: If you use the shoutbox or poll blocks, these make calls to the 'data' directory (which you will have secured via HTTP-auth), which will prompt for logins. Also the preview function on the Guestbook will do this too. To resolve this problem, copy the data/preview.php and data/iframe.php files to the base directory; ocPortal will then be smart enough to find the right ones to use based on the zone the user is in.

You may find that the Flash uploader ocPortal has does not work with HTTP-authentication, as Flash might not be able to provide credentials properly.
To disable it, run this command through OcCLE:

Code


:set_value('no_swfupload','1');

As previously mentioned, but worth re-iterating: ocPortal is only accessible in HTTP-auth enabled areas if the user is actually able to HTTP-authenticate there. ocPortal will then assume that user is logged in. If ocPortal cannot see any HTTP-auth user, it can only be because that ocPortal zone is not secured with HTTP-auth.
This takes some time to get-your-head-around, but makes sense when you do. If it helps, consider the situation like this: with HTTP-authentication, security and authentication is being taken away from ocPortal and moved to another layer- it puts ocPortal in a position to be able to make assumptions by placing a virtual shield in front of it.

Concepts