File: node11.html

package info (click to toggle)
sympa 4.1.5-2
links: PTS
area: main
in suites: sarge
size: 11,504 kB
ctags: 2,195
sloc: perl: 18,884; sh: 4,032; makefile: 1,173; ansic: 226; php: 105; lisp: 32
file content (471 lines) | stat: -rw-r--r-- 17,175 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<!--Converted with jLaTeX2HTML 2002 (1.62) JA patch-1.4
patched version by:  Kenshi Muto, Debian Project.
LaTeX2HTML 2002 (1.62),
original version by:  Nikos Drakos, CBLU, University of Leeds
* revised and updated by:  Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
  Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>10. Authorization scenarios</TITLE>
<META NAME="description" CONTENT="10. Authorization scenarios">
<META NAME="keywords" CONTENT="sympa">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="jLaTeX2HTML v2002 JA patch-1.4">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

<LINK REL="STYLESHEET" HREF="sympa.css">

<LINK REL="next" HREF="node12.html">
<LINK REL="previous" HREF="node10.html">
<LINK REL="up" HREF="sympa.html">
<LINK REL="next" HREF="node12.html">
</HEAD>

<BODY TEXT="#000000" BGCOLOR="#ffffff">
<!--Navigation Panel-->
<A NAME="tex2html929"
  HREF="node12.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> 
<A NAME="tex2html923"
  HREF="sympa.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A> 
<A NAME="tex2html917"
  HREF="node10.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A> 
<A NAME="tex2html925"
  HREF="node1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A> 
<A NAME="tex2html927"
  HREF="node23.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A> 
<BR>
<B> Next:</B> <A NAME="tex2html930"
  HREF="node12.html">11. Virtual robot</A>
<B> Up:</B> <A NAME="tex2html924"
  HREF="sympa.html">Sympa Mailing Lists Management Software version</A>
<B> Previous:</B> <A NAME="tex2html918"
  HREF="node10.html">9. Authentication</A>
 &nbsp <B>  <A NAME="tex2html926"
  HREF="node1.html">Contents</A></B> 
 &nbsp <B>  <A NAME="tex2html928"
  HREF="node23.html">Index</A></B> 
<BR>
<BR>
<!--End of Navigation Panel-->
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>

<UL>
<LI><A NAME="tex2html931"
  HREF="node11.html#SECTION001110000000000000000">10.1 rules specifications</A>
<LI><A NAME="tex2html932"
  HREF="node11.html#SECTION001120000000000000000">10.2 LDAP Named Filters</A>
<UL>
<LI><A NAME="tex2html933"
  HREF="node11.html#SECTION001121000000000000000">10.2.1 Definition</A>
<LI><A NAME="tex2html934"
  HREF="node11.html#SECTION001122000000000000000">10.2.2 Search Condition</A>
</UL>
<BR>
<LI><A NAME="tex2html935"
  HREF="node11.html#SECTION001130000000000000000">10.3 scenario inclusion</A>
<LI><A NAME="tex2html936"
  HREF="node11.html#SECTION001140000000000000000">10.4 Hidding scenario files</A>
</UL>
<!--End of Table of Child-Links-->
<HR>

<H1><A NAME="SECTION001100000000000000000"></A>
<A NAME="scenarios"></A><A NAME="1543"></A>
<BR>
10. Authorization scenarios
</H1>

<P>
List parameters controlling the behavior of commands are linked to different authorization scenarios.
For example : the <A NAME="6165"></A><TT>send private</TT> parameter is related to the send.private scenario.
There are four possible locations for a authorization scenario. When <I>Sympa</I> seeks to apply an authorization scenario, it
looks first in the related list directory <A NAME="6181"></A><TT>/home/sympa/expl/<TT>&lt;</TT>list<TT>&gt;</TT>/scenari</TT>. If it
does not find the file there, it scans the current robot configuration directory <A NAME="6190"></A><TT>/home/sympa/etc/my.domain.org/scenari</TT>, then the site's configuration directory <A NAME="6193"></A><TT>/home/sympa/etc/scenari</TT>,
and finally <A NAME="6196"></A><TT>/home/sympa/bin/etc/scenari</TT>, which is the directory installed by the Makefile.

<P>
An authorization scenario is a small configuration language to describe who
can perform an operation and which authentication method is requested for it.
An authorization scenario is an ordered set of rules. The goal is to provide a simple and
flexible way to configure authorization and required authentication method for each operation.

<P>
Each authorization scenario rule contains :

<UL>
<LI>a condition : the condition is evaluated by <I>Sympa</I>. It can use
  variables such as <IMG
 WIDTH="8" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
 SRC="img1.png"
 ALT="$[$">sender<IMG
 WIDTH="8" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
 SRC="img2.png"
 ALT="$]$"> for the sender e-mail, <IMG
 WIDTH="8" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
 SRC="img1.png"
 ALT="$[$">list<IMG
 WIDTH="8" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
 SRC="img2.png"
 ALT="$]$"> for the listname etc.
</LI>
<LI>an authentication method. The authentication method can be <A NAME="6200"></A><TT>smtp</TT>,
<A NAME="6203"></A><TT>md5</TT> or <A NAME="6206"></A><TT>smime</TT>. The rule is applied by <I>Sympa</I> if both condition
and authentication method match the runtime context. <A NAME="6210"></A><TT>smtp</TT> is used if
<I>Sympa</I> use the SMTP <A NAME="6214"></A><TT>from:</TT> header , <A NAME="6217"></A><TT>md5</TT> is used if a unique
md5 key as been returned by the requestor to validate her message, <A NAME="6220"></A><TT>smime</TT>
is used for signed messages (see <A HREF="node21.html#smimeforsign">20.4.3</A>, page&nbsp;<A HREF="node21.html#smimeforsign"><IMG  ALIGN="BOTTOM" BORDER="1" ALT="[*]" SRC="crossref.png"></A>).
</LI>
<LI>a returned atomic action that will be executed by <I>Sympa</I> if the rule matches

<P>
</LI>
</UL>

<P>
Example

<P>
<BLOCKQUOTE>
del.auth
</BLOCKQUOTE><PRE>
title.us deletion performed only by list owners, need authentication
title.fr suppression rserve au propritaire avec authentification
title.es eliminacin reservada slo para el propietario, necesita autentificacin


  is_owner([listname],[sender])  smtp       -&gt; request_auth
  is_listmaster([sender])        smtp       -&gt; request_auth
  true()                         md5,smime  -&gt; do_it
</PRE>

<P>

<H1><A NAME="SECTION001110000000000000000"></A>
<A NAME="rules"></A>
<BR>
10.1 rules specifications
</H1>

<P>
An authorization scenario consists of rules, evaluated in order beginning with the first. 
Rules are defined as follows :<PRE>
&lt;rule&gt; ::= &lt;condition&gt; &lt;auth_list&gt; -&gt; &lt;action&gt;

&lt;condition&gt; ::= [!] &lt;condition
                | true ()
                | all ()
                | equal (&lt;var&gt;, &lt;var&gt;)
                | match (&lt;var&gt;, /perl_regexp/)
                | is_subscriber (&lt;listname&gt;, &lt;var&gt;)
                | is_owner (&lt;listname&gt;, &lt;var&gt;)
                | is_editor (&lt;listname&gt;, &lt;var&gt;)
                | is_listmaster (&lt;var&gt;)
                | older (&lt;date&gt;, &lt;date&gt;)    # true if first date is anterior to the second date
                | newer (&lt;date&gt;, &lt;date&gt;)    # true if first date is posterior to the second date
&lt;var&gt; ::= [email] | [sender] | [user-&gt;&lt;user_key_word&gt;] | [previous_email]
                  | [remote_host] | [remote_addr] | [user_attributes-&gt;&lt;user_attributes_keyword&gt;]
	 	  | [subscriber-&gt;&lt;subscriber_key_word&gt;] | [list-&gt;&lt;list_key_word&gt;] 
		  | [conf-&gt;&lt;conf_key_word&gt;] | [msg_header-&gt;&lt;smtp_key_word&gt;] | [msg_body] 
	 	  | [msg_part-&gt;type] | [msg_part-&gt;body] | [msg_encrypted] | [is_bcc] | [current_date] | &lt;string&gt;

[is_bcc] ::= set to 1 if the list is neither in To: nor Cc:

[sender] ::= email address of the current user (used on web or mail interface). Default value is 'nobody'

[previous_email] ::= old email when changing subscribtion email in preference page. 

[msg_encrypted] ::= set to 'smime' if the message was S/MIME encrypted

&lt;date&gt; ::= '&lt;date_element&gt; [ +|- &lt;date_element&gt;]'

&lt;date_element&gt; ::= &lt;epoch_date&gt; | &lt;var&gt; | &lt;date_expr&gt;

&lt;epoch_date&gt; ::= &lt;integer&gt;

&lt;date_expr&gt; ::= &lt;integer&gt;y&lt;integer&gt;m&lt;integer&gt;d&lt;integer&gt;h&lt;integer&gt;min&lt;integer&gt;sec

&lt;listname&gt; ::= [listname] | &lt;listname_string&gt;

&lt;auth_list&gt; ::= &lt;auth&gt;,&lt;auth_list&gt; | &lt;auth&gt;

&lt;auth&gt; ::= smtp|md5|smime

&lt;action&gt; ::=   do_it [,notify]
             | do_it [,quiet]
             | reject(&lt;tpl_name&gt;)
             | request_auth
             | owner
	     | editor
	     | editorkey

&lt;tpl_name&gt; ::= corresponding template (&lt;tpl_name&gt;.tpl) is send to the sender

&lt;user_key_word&gt; ::= email | gecos | lang | password | cookie_delay_user
	            | &lt;additional_user_fields&gt;

&lt;user_attributes_key_word&gt; ::= one of the user attributes provided by the SSO system via environment variables. The [user_attributes] structure is available only if user authenticated with a generic_sso.

&lt;subscriber_key_word&gt; ::= email | gecos | bounce | reception 
	                  | visibility | date | update_date
			  | &lt;additional_subscriber_fields&gt;

&lt;list_key_word&gt; ::= name | host | lang | max_size | priority | reply_to | 
		    status | subject | account | total

&lt;conf_key_word&gt; ::= domain | email | listmaster | default_list_priority | 
		      sympa_priority | request_priority | lang | max_size
</PRE>

<P>
(Refer to  <A HREF="node13.html#tasks">12.10</A>, page&nbsp;<A HREF="node13.html#tasks"><IMG  ALIGN="BOTTOM" BORDER="1" ALT="[*]" SRC="crossref.png"></A> for date format definition)

<P>
perl_regexp can contain the string [host] (interpreted at run time as the list or robot domain).
The variable notation [msg_header-<TT>&gt;&lt;</TT>smtp_key_word<TT>&gt;</TT>] is interpreted as the 
SMTP header value only when evaluating the authorization scenario for sending messages. 
It can be used, for example, to require editor validation for multipart messages.
[msg_part-<TT>&gt;</TT>type] and [msg_part-<TT>&gt;</TT>body] are the MIME parts content-types and bodies ; the body is available
for MIME parts in text/xxx format only.

<P>
A bunch of authorization scenarios is provided with the <I>Sympa</I> distribution ; they provide
a large set of configuration that allow to create lists for most usage. But you will
probably create authorization scenarios for your own need. In this case, don't forget to restart <I>Sympa</I> 
and wwsympa because authorization scenarios are not reloaded dynamicaly.

<P>
These standard authorization scenarios are located in the <A NAME="6226"></A><TT>/home/sympa/bin/etc/scenari/</TT>
directory. Default scenarios are named <TT>&lt;</TT>command<TT>&gt;</TT>.default.

<P>
You may also define and name your own authorization scenarios. Store them in the
<A NAME="6229"></A><TT>/home/sympa/etc/scenari</TT> directory. They will not be overwritten by Sympa release.
Scenarios can also be defined for a particular virtual robot (using directory <A NAME="6244"></A><TT>/home/sympa/etc/<TT>&lt;</TT>robot<TT>&gt;</TT>/scenari</TT>) or for a list ( <A NAME="6271"></A><TT>/home/sympa/expl/<TT>&lt;</TT>robot<TT>&gt;</TT>/<TT>&lt;</TT>list<TT>&gt;</TT>/scenari</TT> ).

<P>
Example:

<P>
Copy the previous scenario to <A NAME="6286"></A><TT>scenari/subscribe.rennes1</TT> :

<P><PRE>
equal([sender], 'userxxx@univ-rennes1.fr') smtp,smime -&gt; reject
match([sender], /univ-rennes1\.fr\$/) smtp,smime -&gt; do_it
true()                               smtp,smime -&gt; owner
</PRE>

<P>
You may now refer to this authorization scenario in any list configuration file, for example :

<P><PRE>
subscribe rennes1
</PRE>

<P>

<H1><A NAME="SECTION001120000000000000000"></A>
<A NAME="named-filters"></A>
<BR>
10.2 LDAP Named Filters
</H1>

<P>
At the moment Named Filters are only used in authorization scenarios. They enable to select a category of people who will be authorized or not to realise some actions.

<P>
As a consequence, you can grant privileges in a list to people belonging to an <A NAME="6289"></A>LDAP directory thanks to an authorization scenario.

<P>

<H2><A NAME="SECTION001121000000000000000">
10.2.1 Definition</A>
</H2>

<P>
People are selected through an <A NAME="6290"></A>LDAP filter defined in a configuration file. This file must have the extension '.ldap'.It is stored in <A NAME="6291"></A><TT>/home/sympa/etc/search_filters/</TT>.

<P>
You must give several informations in order to create a Named Filter:

<UL>
<LI>host
<BR>
A list of host:port LDAP directories (replicates) entries.

<P>
</LI>
<LI>suffix
<BR>
Defines the naming space covered by the search (optional, depending on the LDAP server).

<P>
</LI>
<LI>filter
<BR>
Defines the LDAP search filter (RFC 2254 compliant). 
	But you must absolutely take into account the first part of the filter which is:
	('mail_attribute' = [sender]) as shown in the example. you will have to replce 'mail_attribute' by the name 
	of the attribute for the email.
	<I>Sympa</I> verifies if the user belongs to the category of people defined in the filter. 

<P>
</LI>
<LI>scope
<BR>
By default the search is performed on the whole tree below the specified base object. This may be changed by specifying a scope :

<P>

<UL>
<LI>base : Search only the base object.
</LI>
<LI>one
<BR>
Search the entries immediately below the base object. 
</LI>
<LI>sub
<BR>
Search the whole tree below the base object. This is the default. 
	
</LI>
</UL>

<P>
</LI>
</UL>

<P>
example.ldap : we want to select the professors of mathematics in the university of Rennes1 in France<PRE>
	
	host		ldap.univ-rennes1.fr:389,ldap2.univ-rennes1.fr:390
	suffix		dc=univ-rennes1.fr,dc=fr
	filter		(&amp;(canonic_mail = [sender])(EmployeeType = prof)(subject = math))
	scope		sub
</PRE>

<P>

<H2><A NAME="SECTION001122000000000000000">
10.2.2 Search Condition</A>
</H2>

<P>
The search condition is used in authorization scenarios which are defined and described in (see&nbsp;<A HREF="node11.html#scenarios">10</A>) 

<P>
The syntax of this rule is:<PRE>
	search(example.ldap,[sender])      smtp,smime,md5    -&gt; do_it
</PRE>

<P>
The variables used by 'search' are :

<UL>
<LI>the name of the LDAP Configuration file
<BR></LI>
<LI>the [sender]
<BR>
That is to say the sender email address. 
</LI>
</UL>

<P>
Note that <I>Sympa</I> processes maintain a cache of processed search conditions to limit access to the LDAP directory ; each entry has a lifetime of 1 hour in the cache.

<P>
The method of authentication does not change.

<P>

<H1><A NAME="SECTION001130000000000000000">
10.3 scenario inclusion</A>
</H1>

<P>
Scenarios can also contain includes :

<P><PRE>
    subscribe
        include commonreject
        match(, /cru\.fr$/)          smtp,smime -&gt; do_it
	true()                               smtp,smime -&gt; owner
</PRE>

<P>
In this case sympa applies recursively the scenario named <TT>include.commonreject</TT>
before introducing the other rules. This possibility was introduced in
order to facilitate the administration of common rules.

<P>
You can define a set of common scenario rules, used by all lists.
include.<TT>&lt;</TT>action<TT>&gt;</TT>.header is automatically added to evaluated scenarios.

<P>

<H1><A NAME="SECTION001140000000000000000">
10.4 Hidding scenario files</A>
</H1>

<P>
Because <I>Sympa</I> is distributed with many default scenario files, you may want to hidde some of them 
to list owners (to make list admin menus shorter and readable). To hidde a scenario file you should 
create an empty file with the <TT>:ignore</TT> suffix. Depending on where this file has been created
will make it ignored at either a global, robot or list level.

<P>
<I>Example :</I> <PRE>
/home/sympa/etc/\samplerobot/scenari/send.intranetorprivate:ignore
</PRE>

<P>
The <TT>intranetorprivate</TT> <TT>send</TT> scenario will be hidden (on the web admin interface),
at the my.domain.orgrobot level only.

<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html929"
  HREF="node12.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> 
<A NAME="tex2html923"
  HREF="sympa.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A> 
<A NAME="tex2html917"
  HREF="node10.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A> 
<A NAME="tex2html925"
  HREF="node1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A> 
<A NAME="tex2html927"
  HREF="node23.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A> 
<BR>
<B> Next:</B> <A NAME="tex2html930"
  HREF="node12.html">11. Virtual robot</A>
<B> Up:</B> <A NAME="tex2html924"
  HREF="sympa.html">Sympa Mailing Lists Management Software version</A>
<B> Previous:</B> <A NAME="tex2html918"
  HREF="node10.html">9. Authentication</A>
 &nbsp <B>  <A NAME="tex2html926"
  HREF="node1.html">Contents</A></B> 
 &nbsp <B>  <A NAME="tex2html928"
  HREF="node23.html">Index</A></B> 
<!--End of Navigation Panel-->
<ADDRESS>
root
2004-09-10
</ADDRESS>
</BODY>
</HTML>