[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: architecture and security

David T. Perkins wrote:

HI,

Can you describe the problem that you are trying to
solve (instead of TELLing us THE solution). And have
you looked at other solutions, and if so, would
you describe the pros and cons of each.


I think both examples below make sense.

Access by feature classification regardless of XML subtree
location is useful.  This can also be done by locating
related features under a common parent node, but often NE features
have some config data spread out all over the XML tree.
(Some global, per-interface, per-circuit, etc.)

I don't think 'interfaces' is granular enough, or an appropriate feature
category.

A config might look like:

<acme>
  <feature-A> ...
  <feature-B> ...
  <interfaces>
     <interface>
        <name>eth0</name>
        <feature-A> ...
        <feature-C> ...
     </interface>
  </interface>
</acme>

Access to all 'interfaces' in this model doesn't make much sense.
Access to all of 'feature-A' regardless of where the XML is located
makes sense.  Common namespace usage makes this easy.

I also want to point out that nobody is asking for instance granularity
within a row.  People have asked for "user A can look at all instances
of the foo object" or "user B can look at all the data in row X of
the interfaces table".  This is very different than VACM (and much
simpler/better IMO), where the columns in an individual row can have
different access control rights for every user.




Regards,
/david t. perkins


Andy



On Thu, 13 Apr 2006, Balazs Lengyel wrote:

Defining access control on a resource level is a
requirement for Ericsson. This still has two cases:
1) Managed Object type or class based: User A has access
to interfaces but not to routing information, while
user B can only access routing but not interfaces
2) Managed Object instance based: User A can access
IF=eth0 but not IF=eth1 while User B can access
IF=eth1 but not IF=eth0.

Both cases are required for us. Netconf should at
least not make it impossible to implement this.
Balazs

Randy Presuhn wrote:

Hi -


From: "Kent Watsen" <kwatsen@juniper.net>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Thursday, April 06, 2006 8:45 PM
Subject: RE: architecture and security

...

1. When the subscription-request comes in, the system must authenticate
that the request only subscribes to events the client is authorized to
receive

2. However, when each notification is generated by the system, the
system only forwards it to the client if it already has a subscription
in place for that kind of event

In case you think that I'm contradicting my earlier statement
"eliminates the system from having to apply filters to the responses",
what I meant to say is that it eliminates *access control* from having
to apply filters to the responses.  This is true since any notification
matching the subscription request, which was authorized, is also
implicitly authorized to be sent to the client

...

It sounds like these access control policies are only in terms
of the event type, and not in terms of the specific resources
being managed.  In other words, if Customer A should only
be able to access interface (a) configuration data,
and Customer B should only be able to access interface (b),
and the same event type is defined for both interfaces,
we'd have a problem.

Or is this simply one of those things netconf won't support?

Randy


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

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




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





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