ocPortal Tutorial: Integrating ocPortal into a network via HTTP authentication
Authentication via HTTP
Authentication is required to even reach the web application
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
HTTP authentication in ocPortal
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).
Enabling HTTP-authentication recognition in ocPortal
You will likely want to disable joining ocPortal, so only HTTP-auth members may use it
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
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:
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.