Re: architecture and security

["David T. Perkins" <dperkins@dsperkins.com>]

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.

Regards,
/david t. perkins
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/>