RE: a question about Management Authorization -01 document

[li chunxiu <lichunxiu@huawei.com>]

> Dave writes...
> I take it that in this example the Management-Policy-Id is composed of two
> separate elements, "Read-only" which provides an over-riding access
control
> policy of read only, and "group1", which provides some other access
control
> policy, perhaps based on access to certain branches of the management
tree.
> This is exactly the type of implementation that we discourage in the -01
> text.  The content of Management-Policy-Id should be exactly one name of a
> policy of local scope to the NAS.  It should not be composed of
sub-strings,
> each of which separately names a different policy element.  You could
> certainly have a local policy named "read-only-group1" and another named
> "read-write-group1".  That might accomplish your objective.
I agree with the point of view of a local policy named "read-only-group1"
and another named "read-write-group1". 
If the Access Control is mainly done in NAS, the Access Control policy in
Radius may be very simple, and the pattern of "read-only-group1" is ok.
If the Radius needs to participate in the Access Control, there may be some
complicate policies. If the policies are too complicated to be expressed in
one Management-Policy-Id, which expression is better? Will the policies be
separated to several parts in each Management-Policy-Id within each
Access-Accept? And these parts will be composed to be whole policies in the
NAS to accomplish the Access Control, right? 
> This could be workable, in that the Management-Policy-Id is restricted to
a
> single, flat name of local scope (no sub-fields).  It is possible to
define
> a scenario in which two access control provisioning attributes are used in
> the same Access-Accept, but...  It would be necessary to define the
> precedence relationship between them, should there be any conflicts in the
> underlying access control rules that would result from application of the
> polices in the NAS.  That is also feasible to do.
This needs to be researched.
 > The only use case that I can come up with in which it might be beneficial
to
> apply disparate, separately named management policies in a single
> Access-Accept is the proxy RADIUS case, in which the operator of NAS and
the
> first hop proxy RADIUS server may wish to overlay restrictions on the
access
> control provisioned by the operator of the home RADIUS server.  Unless
these
> policies are well coordinated, and the precedence relationships well
> specified, the result may be unpredictable.
I agree.
Comments on this?

Li chunxiu


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>