certi-devel
[Top][All Lists]
Advanced

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

Re: [certi-dev] RE: CERTI security features / was: HLA Plugin for XPlane


From: Martin Spott
Subject: Re: [certi-dev] RE: CERTI security features / was: HLA Plugin for XPlane
Date: Mon, 18 Aug 2008 13:25:31 +0000 (UTC)
User-agent: tin/1.9.2-20070201 ("Dalaruan") (UNIX) (Linux/2.6.26.2 (x86_64))

Hi Petr,

"Gotthard, Petr" wrote:

> thank you for your offer. The people behind firewalls/gateways often get
> their public IP dynamically assigned, so the simple workaround wouldn't
> work.

Hmmm, we're probably talking about two different firewalls. I think at
least the average user will be able to use NAT in order to get past his
own, local gateway/firewall - as long as he uses TCP as RTI transport.

Now, in order to restrict access to the RTI 'server' via packet
filtering I'm thinking of a solution which offers a web page for user
authentication using a browser. Afterwards we're drilling a hole into
the _server_-firewall to allow unrestricted RTIG-access for the same IP
from which the user has been performing his authentication, limited to
a predefined period of time.


> 1) access control
> encrypted authentication very early in the session initiation
> prevent people from accessing the RTIG
> preferrably integrable with LDAP and/or other authentication services

Yup, should my proposed workaround/wrapper _not_ be feasible, then, I'd
say, 1) _is_ a requirement. I just wanted to allow things to get going
without putting pressure upon the CERTI developers. Nevertheless I'd be
happy to see a 'proper' implementation in CERTI !

Although it is by far my personal preference, I'm not certain wether
pure LDAP is the authentication method of choice for the given case. On
the one hand it's quite 'lean', vertaile and allows connecting not only
to Unix LDAP services but also to a M$ Active Directory.

On the other hand I'm thinking of people who'd just like to allow three
or four users connecting to the RTIG and don't want to set up an entire
LDAP service. For this purpose, using SASL, which allows for a simple
'sasldb2' and _optionally_ offers to use LDAP and all the other stuff
as a backend, might evolve as being everyone's friend.

Just my 2 cent, as I won't be the one to shoulder the respective
implementation ....

Cheers,
        Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]