• Data Security and Privacy Design
• Stream Security

Implementation is via the files in /inc/lib_security

The sec_policy.xml file defines the table level security for each module. Each module should contain a separate xml file in it's module root. A sample sec_policy.xml file is given below.

<?xml version="1.0"?>
<sec_policy xmlns="http://www.sahana.lk/security/policy"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.sahana.lk/security/policy sec_policy.xsd">
 
	<usercase name="Organization Registration">
		<functions>
			<function>shn_or_reg_org</function>
			<function>shn_or_reg_org_confirm</function>
			<function>shn_or_reg_org_gis_map</function>
			<function>shn_or_reg_org_cr</function>
		</functions>
		<tables>
				<table perm="c">org_main</table>
				<table perm="r">field_options</table>
				<table perm="r">location</table>
				<table perm="c">location_details</table>
				<table perm="c">contact</table>
		</tables>
	</usercase>
	<usercase name="Organization Registration Edit">
		<functions>
			<function>shn_or_reg_org</function>
			<function>shn_or_reg_org_confirm</function>
			<function>shn_or_reg_org_gis_map</function>
			<function>shn_or_reg_org_cr</function>
		</functions>
		<tables>
				<table perm="u">org_main</table>
				<table perm="r">field_options</table>
				<table perm="r">location</table>
				<table perm="u">location_details</table>
				<table perm="u">contact</table>
		</tables>
	</usercase>
</sec_policy>

• Each use case should be in a separate <usercase> element.
• All functions which are needed in completing the action of the use case should be put in individual <function> elements.
• The function name should be the content of the <function> element.
• Within the <usercase> element all tables(UNION of tables for all the functions in the user case) that are accessed/modified should be included with the appropriate permissions.
• The objective is to fail the entire user case , if one function fails. Thus For Organization Registration , if the user does not have permission to some data in one step of the user case , he should be to stopped in the first step itself. Otherwise it is not user friendly to throw the user out at the last step.
• The permissions are as follows
  
  • c - Create/Insert
  • r - Read/Select
  • u - Update
  • d - Delete

If a use case action tries to perform any operation that is not permitted within the sec_policy.xml, the security system will abort the operation and notify the user with an access denied message.

Tool : sec_policy_gen.pl
Usage : ./sec_policy_gen.pl <module_short_code> <file-1> <file-2> ….

eg: To generate the skeleton for the catalog system. Execute the following in the catalog system module root.

./sec_policy_gen.pl cs main.inc admin.inc 

The sec_policy_gen.pl (this can be found under /tools) is a tool that can be used to generate the skeleton of the sec_policy.xml. This tool will scan through all source files passed in as arguments and include all functions matching “shn_<module_short_code>_*(*)”, in to sec_policy.xml under a single <usercase> element.This file will be saved in the current directory.

• Any existing file with the same name will be overwritten.
  

The module developer needs to add the appropriate <usercase> elements and put the relevant functions in the use cases. Further the tables accessed/modified within the function needs to be manually entered and the appropriate permissisons should be given as described above.