ACLs design
-----------

This document aims at describing the way ACLs can be designed, and how they can
follow an "order relationship" (?) in Nuauth.
This document aims at being an abstract, above any implementation such as LDAP
or XML, and allowing full compatibility of Nufw ACLs scheme regardless of the chosen 
implementation.

o ACL definition
----------------

  Acls are [possibly] defined by
  - SrcIPStart
  - SrcIPEnd
  - DstIPStart
  - DstIPEnd
  - SrcPortStart
  - SrcPortEnd
  - DstPortStart
  - DstPortEnd
  - Time of day }
  - Day of week } These need to be more precisely documented, this is fuzzy.
  - Group ID(s) and decision(s)
  - internal event, such as "this user has logged in before today"
  - external event, such as "the sun is shining now"

o ACL ordering
--------------
  
  Possible ways of ordering ACLs:
  - first seen matches (this is not applicable to LDAP, where no order is
    guaranteed in server's answers)
  - ACls are given a weight, heaviest ACL is applied. In case two or more apply,
    the most restrictive decision of these ACLs is applied.
  - ACL hierarchy. Acls can be set as children of another ACL, the youngest
    generation is the applied one. In case two or more ACLs apply, the most
    restrictive of these ACLs is applied. This implies a recursive parsing of
    ACLs every time a decision must be made.
  - Group hierarchy. This is the chosen way. Groups can be set relative
    priorities, and the decision is the one of the highest priority group if a
    conflict arizes. In case two groups with same priority present conflicting
    decisions, the connection will be refused.
    The way to set priorities to Groups is something like :
     <prio group="101">
      <prio group="102"></prio>
     </prio>
    The above example results in group 102 having a higher priority than group
    101. In case a connection matches both groups, and their decisions are
    conflictual, the decision linked to group 102 will be used.

o Abstraction à la Nagios
-------------------------

  Generic and often used schemes must be extractable, as for instance for working
  hours. This example is formal, and isnt claimed to work verbatim !

  #Define working hours as : monday to friday, 9am to 5pm.
	 <Period name="WorkingHours">
	  	 <StartTime>
			<item type="weekday">monday</item>
			<item type="secday">32400</time>
		 </StartTime>
     		<EndTime>
       			<item type="weekday">friday</item>
       			<item type="secday">61200</item>  #61200 seconds after midnight is 5pm
     		</EndTime>
	 </Period>

  #Define day light :
	<Period name="Daylight">
		<StartTime>
			<item type="hour">08</item>
		</StartTime>
		<EndTime>
			<item type="hour">18</item>
		</EndTime>
	</Period>

  Then, to allow group 101 browsing the web at working hours, and deny that to
  group 102:

  <UDAcl ACLName="WorkingHours">
   <Protocol proto="tcp">
    <DstPortStart port="80">
     <DstPortEnd port="80">
      <SrcPortStart port="1025">
       <Group decision="allow">101</Group>
       <Group decision="reject">102</Group>
      </SrcPortStart>
     </DstPortEnd>
    </DstPortStart>
   </Protocol>
  </UDAcl>

  TODO : Add an LDAP example too.
  TODO : Deal with user's vacation times.
  TODO : expiration of users accounts, though this is not ACL-related.