<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Steve,</p>
<p>I think the installation password is designed to be used in a
protected network environment where you are in control of the
enduser names. The authentication matches the client OS user with
a DBMS user and optional password.<br>
</p>
<p>Most of my sites use Server and Database users with hard coded
vnodes and DSNs. At one site, we have a development effort to
migrate towards a combination of installation password, app/role
passwords and some user passwords. We have been experimenting
with 2FA and temporary passwords to act like a token. It seems
reasonably secure.<br>
</p>
<ul>
<li>OpenROAD challenges AppUser + password, <br>
</li>
<li>Sends a message to the security service to allow a match on
Device, Active Directory User/Group, Application, AppUser,
password.</li>
<li>If matched ok, the service:</li>
<li>- refreshes the the database user: expiry date and temporary
password.<br>
</li>
<li>- sends an SMS with 4-6 digit pin to nominated mobile number.
<br>
</li>
<li>- responds to OpenROAD with a one time token<br>
</li>
<li>The user enters the pin which combines with the token to be
used as the database password</li>
<li>OpenROAD connects to the database.</li>
<li>Application logic uses role/password to allow access to
various tables</li>
<li>2FA function wraps some secure functions like financial
authorisations</li>
</ul>
<p>This is all internally developed with a little bit of C for the
security service and client end DLL. We might dabble with Okta
integration which is already in use at the site. I am also
considering an architecture written in OpenROAD entirely and using
DB events to sent the authorisation messages.<br>
</p>
<p>Paul<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 29/08/2021 5:53 pm, Steve wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9e7e851b-ac1e-4c16-b07c-fe29debb0e97n@googlegroups.com">
<pre class="moz-quote-pre" wrap="">Hi folks
Is using an Installation Password considered less secure, versus say DBMS authentication, when connecting to a remote Ingres installation?
To give some context, I am thinking in terms of a cloud environment where Ingres installations can be spun up and down willy nilly. By spun up, I mean where Ingres is installed and started on a new server instance with the press of a button (well, that’s the theory).
I thought DBMS authentication maybe more secure for connecting to a remote instance - presumably each user is prompted for their password when connecting. However, this would require the newly created Ingres installation to have the user information in order to authenticate the user.
Also, this ignores the fact that the cloud provider will have their own layer of security.
Any thoughts (apart from don’t over think it)?
Thanks
Steve
_______________________________________________
Info-ingres mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Info-ingres@lists.planetingres.org">Info-ingres@lists.planetingres.org</a>
<a class="moz-txt-link-freetext" href="https://lists.planetingres.org/mailman/listinfo/info-ingres">https://lists.planetingres.org/mailman/listinfo/info-ingres</a>
</pre>
</blockquote>
<div class="moz-signature">-- <br>
Paul White<br>
Shift Seven Solutions<br>
<b>m: 0414681799</b><br>
p: 0754482137<br>
e: <a class="moz-txt-link-abbreviated" href="mailto:paul.white@shift7solutions.com.au">paul.white@shift7solutions.com.au</a><br>
w: <a class="moz-txt-link-freetext" href="https://www.shift7solutions.com.au">https://www.shift7solutions.com.au</a><br>
International: +61414681799<br>
</div>
</body>
</html>