Thread: Security setup.

Security setup.

From
Date:
<table align="center" bgcolor="#ffffff" border="0" cellpadding="0" cellspacing="0" style="empty-cells: show;"
width="100%"><tr><td;=";" </td="</td" align="left" background="cid:top@e13e1eb3de623676fe6c48dabdfd3e15" colspan="1"
height="72"style="text-align: left; background-repeat: no-repeat;"></td></tr><tr><td style="vertical-align: top;"><div
style="padding:5px; overflow-x: auto;"></div></td></tr></table><span style="font-family:Verdana; color:#000000;
font-size:10pt;"><div>Wehave a very solid security appliance which sits in front of our domain controller.  All traffic
fromour users is also controlled via a citrix login and they only have access to the published apps, no
desktops.</div><div><br/></div><div>We have been thinking of using trust as our security method.  If we decide to use
thiswill we be required to enter the users into the database?</div><div><br /></div><div>The other option might be
usingSSL and entering in the users to the db.  We still have to build internal security tables which handle procedure
anddata level security so pushing the login to the database isn't that big of a deal.<br /></div><div><br
/></div><div>MichaelGould</div><div>Intermodal Software Solutions, LLC</div><div>904-226-0978</div></span> 

Re: Security setup.

From
Sim Zacks
Date:
The problem with trust is that it means that any user can type in any
other users login name and get access without knowing his password. Even
if your app is the only access point to the database, you still have to
worry about a user installing psql or other client onto his desktop and
accessing the database directly.

If your application is logging in, you still don't want to use trust
because you can put the password into the application. The level of
security that you require will depend a lot on the application
infrastructure. For example, if you are using an application server then
you can limit access of the database to the IP address of the app server
and the DBA's computer. That way you don't have to worry about anybody
installing a rogue client.

Sim

On 09/10/2011 10:42 PM, mgould@isstrucksoftware.net wrote:
>
> We have a very solid security appliance which sits in front of our
> domain controller.  All traffic from our users is also controlled via
> a citrix login and they only have access to the published apps, no
> desktops.
>
> We have been thinking of using trust as our security method.  If we
> decide to use this will we be required to enter the users into the
> database?
>
> The other option might be using SSL and entering in the users to the
> db.  We still have to build internal security tables which handle
> procedure and data level security so pushing the login to the database
> isn't that big of a deal.
>
> Michael Gould
> Intermodal Software Solutions, LLC
> 904-226-0978
>


Re: Security setup.

From
Sim Zacks
Date:
On 09/11/2011 02:58 PM, mgould@isstrucksoftware.net wrote:
>
> Sim,
>
> Thanks, our users can only get to the application(s) they have on
> their citrix menu.  They are locked out of the servers otherwise.  I
> haven't had a problem in the past 20 years with another db back end
> but I do think that on the whole I probably ought to consider a
> regular login.  I have a few customers that wanted integrated logins
> to active directory which was easy with SQL Anywhere but I guess that
> I would have to use LDAP in order to get that to happen.
>
> Best Regards
>
> Michael Gould
> Intermodal Software Solutions, LLC
> 904-226-0978
>
We use LDAP for authentication, but the user also has to be in the
database. Using LDAP is as easy as adding something like this to your
pg_hba.conf:
ldap "ldap://my-ldap-server.domain/Users;uid=;,ou=Users,dc=domain,dc=local"
Even with nobody being able to use their own client, with trust
authentication, anybody could log in as anybody else without knowing
their password

Sim

Re: Security setup.

From
Chris Travers
Date:
On Sun, Sep 11, 2011 at 12:44 AM, Sim Zacks <sim@compulab.co.il> wrote:
> The problem with trust is that it means that any user can type in any other
> users login name and get access without knowing his password. Even if your
> app is the only access point to the database, you still have to worry about
> a user installing psql or other client onto his desktop and accessing the
> database directly.
>
> If your application is logging in, you still don't want to use trust because
> you can put the password into the application. The level of security that
> you require will depend a lot on the application infrastructure. For
> example, if you are using an application server then you can limit access of
> the database to the IP address of the app server and the DBA's computer.
> That way you don't have to worry about anybody installing a rogue client.
>
This is just about exactly right.  Trust means you trust anyone on the
host to be who they say they are.  It's not generally a good thing,
though restricting it to a specific IP address can be useful
sometimes.

Typically I think a lot of people see trust authentication as an
emergency restore option rather than an actual operating method of
security.  I.e. if your dba changes the passwords as an act of
sabotage and then quits you have an option for the new dba to log in
and set new passwords.  In general though nothing good can  come out
of widely trusting authentication to users.

Best Wishes,
Chris travers