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