Menu
▾
▴
Re: Access Security
|
From: Ralph L. <Ral...@be...> - 2010-01-29 16:39:40
|
Hmm .....
Where do we put configuration data for the credential plug-ins?
Andrew was suggesting to in include that as value in the <credential>,
so that the value can be passed to the plug-in at init, and the plug-in
would parse its own config data. (Config data being anything the
credential plug-in may need: key footprints, URLs where to get keys or
where to find an authentication service, ... whatever.)
Why did you remove the wrappers for credentials and groups? Allowing a
wild mixture of credential, group, state, and asg definitions doesn't
seem to make things more obvious, does it? I like the idea of clearly
marking the sections.
I like the idea of putting the method in the <credential> value, though,
as we probably should allow for an ordered list of methods to be tried
for a certain credential. (Like ssh tries publickey, then whatever, then
passwd.) Allowing config data for plug-ins then needs another tag.
That would make it:
<credentials>
<credential name="host">void</credential>
<credential name="user">[publickey,sharedkey,passwd]</credential>
<credential name="ip">client-ip</credential>
<plugin name="publickey">
<keyserver proto="openpgp">1.keyserver.mylab.org</keyserver>
<keyserver proto="openpgp">2.keyserver.mylab.org</keyserver>
<!-- anything the plug-in would be able to parse -->
</plugin>
</credentials>
Within <rule>, level and access are mandatory and have always exactly
one value. That should make them attributes, to increase legibility and
(drastically!) shorten the AS file.
<rule> and <process> are at the same level, both defining rules. So
<rule> should maybe changed to <access>?
For the <log...> things: as Andrew pointed out, we might want to have
read access, write access, process, or even subscriptions logged. Also,
experience shows that it would be really useful to filter logging by
access group. For a slow feedback loop spanning IOCs, I do not want to
log the loop writes, but all other writes (if the feedback is off). We
don't need a value that defaults to false: if <log> is defined, we want
logging.
So - what about:
<asg name="mygroup">
<access level="1" right="write">
<state name="shutdown">1</state>
<log type="write">
<excludegroup>[name,...,name]</excludegroup>
<!-- multiple excludegroup definitions may follow -->
</log>
<group>[name,...,name]</group>
<!-- multiple group definitions may follow -->
</access>
<!-- an arbitrary number of access rules may appear -->
<process>
<state name = "name">value</state>
<log>
<excludegroup>[name,...,name]</excludegroup>
<!-- multiple excludegroup definitions may follow -->
</log>
<group>[name,...,name]</group>
<!-- multiple group definitions may follow -->
</process>
<!-- an arbitrary number of process rules may appear -->
</asg>
What do you think?
Ralph
On Fri 29 Jan 2010 7:24:23 Marty Kraimer wrote:
> ------------------------------------------------------------------------
>
>
> Syntax Definition
>
> An access security configuration file must start and end as follows:
>
> <?xml version="1.0" ?>
> <accessSecurity>
> <!-- uag, hag, asg definitions -->
> </accessSecurity>
>
> ??? Should accessSecurity tag define xmlns or xsi ?
>
> Between the accessSecurity tags the following definitions appear:
>
>
> <credential name="name">method</>
> <!-- an arbitrary number of credentials can follow-->
> <group name="name" credential="name">[name,...,name]</group>
> <!-- an arbitrary number of groups can be defined -->
> <state name = "name" extends = "accessSecurityState">
> <!-- this is a pvData structure -->
> <!-- has fields named 1) value which has type boolean, 2) alarm, and 3) input which is a structure-->
> <!-- input must attach to support that sets the value field. May by a calculation -->
> </state>
> <!-- an arbitrary number of states may appear -->
> <asg name = "name">
> <rule>
> <level>level</level>
> <state name = "name">value</state>
> <logWrite>value</logWrite>
> <access>access</access>
> <group>[name,...,name]</group>
> <!-- multiple group definitions may follow-->
> </rule>
> <!-- an arbitrary number of rules may appear -->
> <process>
> <state name = "name">value</state>
> <logProcess>value</logProcess>
> <group>[name,...,name]</group>
> <!-- multiple group definitions may follow-->
> </process>
> <!-- an arbitrary number of process rules may appear -->
> </asg>
> <!-- an arbitrary number of asgs can be defined -->
>
> Where
>
> credential
>
> A credential has a name and a method that selects the plugin that
> is used on the server for authentication For example "void" just
> uses the response from the client, "sharedkey" does some real
> work, "client-ip" yields the client's IP number from PVAccess.
>
> group
> This provides a way to associate an array of names with the group
> name.
> state
> This has the same syntax as a pvData structure. The state
> structure has a scalar boolean field named value and an alarm
> field as defined by pvData. The state structure also has a
> structure field named input. The input structure can be
> initiliized just like a structure field for the javaIOC, i.e. it
> can have attached support. One example is the channel access link
> support implemented by the javaIOC. Another example is a
> combination of calculation and link support. The support must
> provide a value for state.value, i.e. it must produce a boolean value.
> asg
>
> An access security group. The group ”default” is a special case.
> If a record specifies a null group or a group which has no asg
> definition then the member is assigned to group default.
>
> asg.rule
> This defines access permissions.
> asg.rule.level
> level refers to the access security level for fields. For now only
> levels 0 and 1 are used.
> asg.rule.state
> The name of the state that determines if this rule is active.
> asg.rule.logWrite
> If value is set to true than all puts that match this rule will be
> trapped. See the section below on trapping Channel Access writes
> for details. The default is false.
> asg.rule.access
> Permission for a level 1 field implies permission for level 0
> fields. The permissions are none, read, and write. write
> permission implies read permission.
> asg.rule.group
> The groups to which are allow access. A logical AND is done within
> a group and a logical OR between groups.
> asg.process
> This defines pemission to request processing. State and group are
> just like for asg.rule. logProcess is similar to asg.logWrite.
>
> The access privilege for a channel access client is determined as follows:
>
> 1. The ASG associated with the record is searched.
> 2. Each RULE is checked for the following:
> * The field's level must be greater than or equal to the
> level for this RULE.
> * If state is specified, the state must be true. If the
> state has alarm severity invalid than the calculation is
> considered false.
> * For each group a logical AND is prrformed for each name. A
> logical OR is issued for between multiple groups If no
> group is not defined all it means access is allowed.
> * If the rule does not apply then access is none.
> 3. The maximum access allowed by step 2 is the access chosen.
> 4. PROCESS priviledge is checked for the following:
> * If state is specified, the state must be true. If the
> state has alarm severity invalid than the calculation is
> considered false.
> * For each group a logical AND is prrformed for each name. A
> logical OR is issued for between multiple groups If no
> group is not defined all it means access is allowed.
> * If the rule does not apply then access is none.
> 5. If any of the PROCESS rules alow process access that process is
> allowed otherwise it is not allowed.
>
> Multiple RULEs can be defined for a given ASG, even RULEs with
> identical levels and access permission. Multiple PROCESSs can be
> defined for a given ASG.
>
|