[AGENT++] Session

[Fehde, Marcus]

Frank,

Thank you for your response. We solved the problem in the meantime and found an appropriate solution.
We're using the contextEngineId to distinguish between the session owner and the others.
The session owner "knows" the lock which is nothing else than a randomly generated string used as contextEngineId.
We're intercepting each incoming and outgoing message. When the agent received a message containing the lock we exchange the contextEngineId with the original contextEngineId (== snmpEngineId). Furthermore we select a particular view that has no restrictions. The view of the non-session owners is reconfigured and contains only the objects required to acquire the session and find out whether a session is already open. Before the response is sent we exchange the contextEngineId again. Fortunately we had to make just a few changes on the library to implement this solution. Since we work only with our own management applications this solution is doable.

Best regards,
Marcus

-----Original Message-----
From: Frank Fock [mailto:fock at agentpp.com] 
Sent: Montag, 24. Januar 2005 23:52
To: Fehde, Marcus
Cc: Agent++ Mailing List
Subject: Re: [AGENT++] Session


Hi Marcus,

Almost missed your posting! Really late - here is my response: Another "solution" for the session problem, would be to use TCP instead of UDP, but this would need some implementation effort for SNMP++ (and AGENT++).

With minmal effort, your solution 1 is my favorite. The "drawback" of the unsecure report can be avoided if the manager does not set the reportable flag.

Best regards,
Frank

Fehde, Marcus wrote:

>Frank,
> 
>we're obliged to implement a session concept for exclusive access to 
>our SNMP agent by one management application at a time.
>Up to now, we followed two different approaches which have one thing in common:
>There's a particular MIB object that provides a lock string. This lock has to be retrieved in order to generate the information required by a management application to identify itself as the session owner. This object isn't any longer readable after the session was acquired and hence other managers can't acquire the session.
>The acquired information are used for
>1. generating a particular user account. Both sides know the generation rules, but only the lock owner and the agent know the key. Within the agent USM and VACM are configured accordingly. One disadvantage of this approach is that (e.g. after a timeout) a subsequent request would cause an unsecured report (unknownUser).
>2. generating a particular context name (or contextEngineId). Every incoming PDU is examined whether it contains the secret session context and if so the context is exchanged for the default context. This means that we would have something like a virtual context. The biggest disadvantage of this approach is that this would have a big impact on the library since the context is used on multiple places.
> 
>We're aware that these approaches would prevent from using standard 
>management tools or at least complicate it. But this doesn't matter 
>since our agent is supposed to be used with our own management tools. Anyhow we don't want to change the general SNMP standard at all. All company specific extensions shall base on the official standards.
> 
>Do you have any suggestions, e.g. different approaches or comments on 
>our approaches? Thank you in advance.
> 
>
>Best regards/Mit freundlichen Gruessen
>
>Marcus Fehde
>Dipl. Ing. Technische Informatik (FH)
>
>Research & Development
>Business Unit Anaesthesia 
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>
>DRÄGER MEDICAL
>
>Dräger Medical AG & Co. KGaA
>Moislinger Allee 53-55 
>D-23542 Lübeck 
>
>Tel:  + 49-451-882-3646
>Fax: + 49-451-882-4410 
>E-mail: marcus.fehde at draeger.com 
>www.draeger-medical.com 
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>
> 
> 
>  
>
>-----------------------------------------------------------------------
>-
>
>_______________________________________________
>AGENTPP mailing list
>AGENTPP at agentpp.org http://agentpp.org/mailman/listinfo/agentpp
>  
>


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
Url: http://lists.agentpp.org/pipermail/agentpp/attachments/20050125/0b714499/attachment.txt