Portal Access Control

General Information

Permissions can be examined by inspecting the .htaccess files: all such files should contain the owning conduit as a comment in their first line, e.g.:

 # Conduit: TP000_Reports_UPT_Admin_Access

Any that do not do this are cause for concern.

Remember, since ACLs are ultimately defined by the result of conduit execution, changes will not take effect until the appropriate TP000_[...]_Access conduit has been run (you can determine which by examining the first line of the appropriate .htaccess file. So any change will await the next periodic refresh, but a manual run of the appropriate conduit on the portal server will hasten it.

Updating access lists

Portal access control is determined by a number of mechanisms, many of which are, alas, transitional and temporary, but all simply generate .htaccess files within the portal's document root.

To determine which method best suits your candidate user depends on the conduits to which they are likely to need access, the type of user, and the timescale of their access:

(a) In-report

Ultimately, portal access permissions are defined by the appropriate TP000_[...]_Access conduit which generates the .htaccess file in the appropriate directory. These reports pull in a number of gurgle variables which act as user category lists.

In some interim conduits these lists are defined manually, but these have largely been replaced by LCFG definition. However it is useful to examine the conduits to determine the access level defined to different groups. Look for variables of the form PORTAL_ACCESS_[...]

Don't forget to wait for / force a refresh, as noted above.

(b) Portal server(s): LCFG definition

Could be defined in theon-portal-server.h core/live headers or machine profiles, depending on permanence, staff category, or breadth of access required. Administered by C(S)Os, obviously, since it is maintained in LCFG space.

Not really appropriate for anyone whose portal requirements are temporary since removal is completely manual and there are no processes for prompting removal; access will remain for the useful life of the account. However until capability-based access is fully functional this is the best we have.

Different categories of staff (and therefore access) are defined using the variables as described above. Add the user to the most appropriate group as defined by the gurgle variable. For example, ISS staff are controlled in =portal.theon='s profile with:

%%define PORTAL_ACCESS_ISS_USERNAMES [...]

Don't forget to wait for / force a refresh, as noted above.

(c) Duty / Role assignment

In database; administered by ISS... details to follow. This is the correct mechanism for Academic staff and students and allows automatic, session-based addition and removal.

in the future it might be appropriate to add similar roles to other categories of staff through their contract types, but this is pending on full 3g staff management.

ISS staff are usually prepared to wait for a refresh, but it can be forced as noted above in extremis.

(d) DICE capability-based

It is not currently possible (as far as I know) to grant portal access by the DICE role/capability mechanism, but I would see this as the ideal for many purposes as it allows access to be granted either by database or role inheritance. Details pending...

-- TimColles - 30 Nov 2018