Detailed Design Specification
© 2006, 2010, 2012 Actian Corporation
Project Name
DBMS Authentication
Author Gordon Thorpe and Karl Schendel
Last Saved Date
March 8, 2016
Revision
Template Revision 1.9 (but should match 2.0)
DBMS Authentication
Responsibility List
Assigned To
Action
Responsibility
Owner
Engineer/Architect
Peer Review
Peer Review
Development Manager
Test Review
QA Engineer
Peer Review
Sustaining Engineering Manager
Sustainability Review
Sustaining Engineering Engineer
Pam Fowler
Peer Review
Level 1 Support Manager
Ahmed Ezzat
Peer Review
Chief Architect
Elaine Grieco
Peer Review
Technical Writer
Peer Review
Services
Peer Review
Services
Chris Rogers
Signature
QA Manager
Jonathan Rosen
Alex Hanshaw
Lee Howard
Note: The Responsibility List reflects those required to review and provide feedback
for the document. Signoff by those listed is required prior to the beginning of the
development phase.
Additional reviewers
DBMS Authentication106763433
Page 2 of 44
Assigned To
Action
Responsibility
Karl Schendel
Information
DBMS
Teresa King
Information
Gateways
Teresa King
Information
Connectivity
Joe Kronk
Information
OpenROAD
Roger Whitcomb
Information
Tools
Emma McGrattan
Information
Usability
Signature
Note: The additional reviewers list reflects other people that should be copied on the
document and invited to review meetings, but feedback from them is not required for
the document to be approved. Managers of other engineering groups are copied for
comment on how it affects their product or product area. The manager for your own
engineering area is included in first table and can be removed from here.
SQL Language Review
DBMS Authentication106763433
Page 3 of 44
Assigned To
Action
Responsibility
Ian Kirkham
Language Review
DBMS
Teresa King
Language Review
Gateways
Teresa King
Language Review
Connectivity
Joe Kronk
Language Review
OpenROAD
Alex Hanshaw
Language Review
Supportability and
Backward
Compatibility
Signature
Note: The SQL language review table lists people that should be sent an initial draft
copy of this document if you answered “yes” to any questions in section 2.2. If you did
not answer yes to any of those questions you may delete this table.
DBMS Authentication106763433
Page 4 of 44
Change History:
Revision Date
Last Revision By
Description of Change
24-May-2012
Chris Clark
8-Aug-2012
Karl Schendel
Numerous refinements, -user/--host options
14-Aug-2012
Karl Schendel
Delete --host, change -user to -user
22-Aug-2012
Karl Schendel
Include user description idea
28-Aug-2012
Karl Schendel
-user passes remote; editorial clarifications
7-Sep-2012
Karl Schendel
CHANGE_PASSWORD is a privilege, not a withoption; clarify
1-Nov-2012
Karl Schendel
SAVEPASSWORD works with -user=uname
password prompt
Initial Draft
DBMS Authentication106763433
Page 5 of 44
TABLE OF CONTENTS
1
2
INTRODUCTION ............................................................................................................. 10
1.1
SCOPE AND SUMMARY.......................................................................................................... 10
1.2
DEFINITIONS, ACRONYMS AND ABBREVIATIONS ........................................................................ 13
1.3
REFERENCES ....................................................................................................................... 15
1.4
NOTEWORTHY ISSUES........................................................................................................... 16
ARCHITECTURE OVERVIEW ............................................................................................ 17
2.1
HIGH LEVEL DESCRIPTION ...................................................................................................... 17
2.2
SQL LANGUAGE CHANGES..................................................................................................... 23
2.3
IMPLICATIONS FOR GCA ....................................................................................................... 25
2.4
CONNECTION PARAMETERS ................................................................................................... 25
2.5
LANGUAGE, UNICODE AND INTERNATIONALIZATION ISSUES ......................................................... 26
2.6
IMPLICATIONS FOR INGRES/STAR ............................................................................................ 26
2.7
IMPLICATIONS FOR DBA TOOLS ............................................................................................... 26
2.8
NEW IMA/MIB OBJECTS......................................................................................................... 27
2.9
NEW TRACE POINTS .............................................................................................................. 27
2.10
CATALOG ALTERATIONS ..................................................................................................... 27
2.11
IMPLICATION FOR GATEWAYS ............................................................................................ 28
2.12
IMPLICATIONS FOR DATABASE DRIVERS ................................................................................ 28
2.13
IMPLICATIONS FOR OPENROAD ........................................................................................... 28
2.14
DESIGN LIMITATIONS AND ASSUMPTIONS ............................................................................ 28
DBMS Authentication106763433
Page 6 of 44
3
4
5
2.15
PLATFORM SPECIFIC ISSUES ............................................................................................... 29
2.16
PRODUCT INTERACTION .................................................................................................... 29
2.17
PATENT INFORMATION ..................................................................................................... 29
EXTERNAL SPECIFICATION ............................................................................................. 30
3.1
USER PERSPECTIVE ............................................................................................................... 30
3.2
INSTALLATION AND ADMINISTRATION PERSPECTIVE ................................................................... 32
3.3
MIGRATION ISSUES .............................................................................................................. 32
3.4
SECURITY IMPACT ................................................................................................................ 33
INTERNAL SPECIFICATION .............................................................................................. 34
4.1
ESTIMATED TASKS AND EFFORT .............................................................................................. 34
4.2
PROGRAMMING .................................................................................................................. 35
4.3
COMPATIBILITY LIBRARY INTERFACE CHANGES ........................................................................... 36
4.4
INTERFACE .......................................................................................................................... 36
4.5
BUILD IMPLICATIONS ............................................................................................................ 37
4.6
UI RESOURCE/PROPERTIES FILES............................................................................................ 37
4.7
BITMAP RESOURCES ............................................................................................................. 37
4.8
ICON FILES.......................................................................................................................... 38
4.9
PICCOLO CHANGE NUMBERS .................................................................................................. 38
IMPACT AND DOCUMENTATION SUMMARY .................................................................. 39
5.1
PRODUCT/COMPONENT IMPACTS .......................................................................................... 39
5.2
DOCUMENTATION ............................................................................................................... 39
DBMS Authentication106763433
Page 7 of 44
6
QUALITY ISSUES ............................................................................................................ 41
6.1
UNIT TESTING SUMMARY...................................................................................................... 41
6.2
HANDOFFQA IMPACT ............................................................................................................ 41
6.3
TESTING RECOMMENDATIONS ............................................................................................... 41
6.4
REGRESSION RISK ASSESSMENT.............................................................................................. 42
7
PACKAGING AND INSTALLATION IMPACT ....................................................................... 43
8
SUPPORT IMPACT.......................................................................................................... 44
8.1
EXAMPLES AND TESTS ........................................................................................................... 44
DBMS Authentication106763433
Page 8 of 44
PREFACE
This document describes external functional specifications as well as design
specifications for one feature of a release project. There will be many Detailed
Design Specifications (DDS) for each project, one for each major feature
described in the Software Requirements Specification (SRS) or project wiki page.
The SRS or the wiki page is the master document for the entire project.
This is intended to be a living document. The product development cycle is a
dynamic process in which our understanding of the project and its criteria for
success are refined over time. It is therefore expected that the completed
Detailed Design Specification will undergo many revisions during the course of a
project as requirements; resources and constraints evolve. The engineer would
not be expected to complete all sections in the initial draft; some sections are
designed so that they can only be completed one the project is coded. *NOTE:
that you are expected to continue updating this document until the release
project is handed over to SE*
The Development Manager is responsible for the contents of this document.
Deliverables that must be completed prior to releasing this document are at least
one of:
 Software Requirements Specification
 Wiki page on the engineering web describing the components of the project
All template instructions can be identified by their gray italic type. This information
may be removed after completing the necessary project information.
Ant information detailed in this document should not be repeated in the wiki page
for this feature unless there is a compelling reason to do otherwise one of the
copies of the information may become out-of-date. If you need to, refer to the DDS
on the wiki page.
DBMS Authentication106763433
Page 9 of 44
1 INTRODUCTION
1.1 SCOPE AND SUMMARY
Explain what the feature is expected to do; notes on the drivers for this feature
(such as partner or customer requirements) should be placed in here.
It is becoming more common for Vectorwise POCs to ask if DBMS authentication
support can be provided, as that is what they use for other DBMSs. “DBMS
authentication” here generally means some variation on “I want to be able to set
up a DBMS user and password entirely within the DBMS.” Ingres customers
have requested this in the past as well. This has occurred enough times that
there are wiki pages on how to simulate Oracle-like authentication, see
http://community.actian.com/wiki/DBMS_Authentication_Workarounds
DBMS authentication is not just a "that's the way we've always done it" feature.
The installation administrator is very likely not the same as the OS system
administrator. Adding an OS user every time a DBMS user is needed causes
delays at best, and corporate political problems at worst. OS admins may see
the need for additional OS users as a security risk, especially when the user is to
be restricted to DBMS use anyway (which is fairly common).
This spec describes an enhancement to provide DBMS authentication by
allowing the DBMS server to authenticate a username/password against the
Ingres defined username and (database) password, with no reference to OS
users or passwords.
Enhancement request details.
Service Desk 119327
SIR 118552
For the purpose of this document, wherever Ingres is mentioned also assume
Vectorwise, EA, and EDBC.
1.1.1.1 Motivation
Many users are familiar with database authentication that is commonly used to
access other databases such as Oracle and MS SQL Server. Ingres (and with
DBMS Authentication106763433
Page 10 of 44
that Vectorwise) does not directly provide database authentication. As a result
numerous users have difficulties configuring authentication for Ingres/Vectorwise.
The requirements for this capability are driven by a comparison between
functionality other DBMS vendors provide versus the way Ingres users have to
configure authentication.
1.1.1.2 Must-have requirements
Mark Van de Wiel, the Vectorwise Product manager provided the following list of
requirements.

Ingres/ Vectorwise must be able to use database-level authentication. I.e.
a user who is defined in the database and not at the OS level (or in a
global directory) must be able to connect to the database using a valid
username/password.

Passwords have to be encrypted on disk to prevent malicious users from
getting easy access to the database.

Passwords must be encrypted when passed over the network to prevent
network sniffers from getting easy access to the database.

Administrative users must be able to get access to the instance using a
means that bypasses database authentication. This may be an existing
authentication method.

Future versions of Ingres/Vectorwise that implement new authentication
capabilities must be backwards compatible with current authentication
methods. Backwards compatibility may be enabled through a
configuration setting which, when changed, breaks backwards
compatibility. New installations may set the new authentication method
whereas existing system upgrades would keep the existing method.

Statements to set and modify passwords must be provided as well as GUI
support for changing passwords.
DBMS Authentication106763433
Page 11 of 44
1.1.1.3 Nice-to-have requirements

Administrators should be able to block users without having to delete
them (e.g. lock the user).

Administrators should be able to set password rules such as minimum
length, minimum complexity requirements, expiration time, number of
failed login attempts, etc.

Administrators should be able to use SSL key verification.

A local OS user, even if known to the Ingres/Vectorwise database through
OS authentication, should be able to impersonate another user by using a
valid username/password combination.
This project will allow users to be managed solely in the DBMS using existing
Ingres mechanisms, such as; “CREATE USER…” SQL statements, accessdb,
VisualDBA, Actian Director, third party DBA tools, etc.
Users who know a username and password should be able to connect as that
user without any restrictions, both locally and remotely. Current mechanisms for
providing username/password should work with the new system, allowing old
clients to connect to new DBMS authentication servers; i.e. vnodes on older
clients should work with new servers configured for DBMS authentication.
SQL monitor tools should work with the new authentication system. For example,
Oracle users can connect with sqlplus (the Oracle SQL terminal monitor) locally
and remotely by specifying the username and password, examples:
Oracle local, explicitly specify username and password
> sqlplus username/password
Oracle remote, explicitly specify username, password, and host
DBMS Authentication106763433
Page 12 of 44
> sqlplus username/password@remotehost
Oracle local, explicitly specify username, user is then prompted for
password
> sqlplus username
Enter password:
Oracle local, user prompted for both username and password
> sqlplus
Enter user-name:
Enter password:
Ingres should offer similar functionality (albeit with different syntax).
1.2 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
Provide the definitions of terms, acronyms and abbreviations required to
interpret this document. For consistency, use the format in the examples below:
Detailed Design Specification: (DDS) A representation of a software system or
component of a system created to facilitate analysis, planning, implementation
and decision-making. The DDS is used as the primary medium for
communicating software design information.
accessdb: original Ingres forms based DBA tool, used to create DBMS users
and manage iidbdb.
Actian Director: New GUI tool for Ingres, similar to Microsoft’s Management
Console
BUGS: bug and enhancement tracking system, tied to Piccolo
dbauth: short hand for DBMS Authentication, the aim of this project
DBMS Authentication106763433
Page 13 of 44
EDBC: Server that allows Ingres SQL and datatypes to be used with foreign
mainframe (which may or may not be relational) databases such as IBM DB2,
CA-Datacom, VSAM, IDMS, etc.
Enterprise Access: Ingres server that allows Ingres SQL and datatypes to be
used with foreign relational SQL databases such as Oracle, Microsoft SQL
Server, and IBM DB2 for Unix, Linux, and Windows.
Forms / FRS: the Ingres console/text based windowing system. Similar to (but
predates) curses.
Gateway: In this document this refers to the Enterprise Access product or EDBC.
GCA: General Communication Application interface, GCA provides the
mechanism through which front-ends, back-ends, and distributed back-ends
access GCF services.
GCF: General Communication Facility, used to send commands a data between
heterogeneous components
GCC / IIGCC: Communication server used to talk to remote clients/servers.
GCD / IIGCD / DAS Server: Data Access Server, special communication server
(like GCC). DAS is used by both JDBC and .NET clients.
GCN / IIGCN: Name server, keeps track of all servers in an Ingres installation.
iidbdb: the Ingres database of databases, used to keep track of users, groups,
databases, etc. Meta data database for the installation.
II_SYSTEM: Environment variable that indicates which Ingres installation to use
locally
Ingres Net: name of the remote communication protocol used when making use
of vnodes and GCC
Kerberos / krb: Kerberos V5 http://web.mit.edu/kerberos/ is a network
authentication protocol, it has been integrated into Windows Active Directory. It
offers encrypted traffic and SSO.
Local user: a user who is logged into the operating system, attempting to
connect to an Ingres DBMS in the current installation (i.e. II_SYSTEM for user
matches target DBMS)
netutil: Forms based admin tool for maintaining vnode definitions
DBMS Authentication106763433
Page 14 of 44
OS: In this document Operating System (and not Open Source)
Piccolo / p2: Actian / Ingres source code control system, precursor to Perforce
(p4)
Remote user: A user connecting to a remote DBMS installation (either across
Ingres Net or via the GCD)
SD: Service Desk, the issue tracking system used at Actian.
SIR: Enhancement request (system improvement request) in the BUGS system
SSO: Single Sign On, allows users to authenticate once with a central server (for
example, Windows Active Directory of Kerberos) and allows access to different
servers and resources without need to specify a username and password.
User impersonation: Connecting as user another user to a DBMS. E.g. local OS
user fred connecting as jim in the DBMS
vdba: Visual DBA, Windows specific GUI admin tools. Actian Director is intended
to replace this tool and be cross platform.
vnode: Virtual Node, used to access remote servers. Vnodes are a shortcut (like
ODBC Data Source Definitions) to a remote database, they include; host name,
protocol, and port as well as optional authentication information. They are similar
to Oracle’s TNS name (but with authentication support). It is not uncommon to
see users refer to vnodes when they really mean using Ingres Net to a remote
server (i.e. the mechanism not the actual vnode definition).
1.3 REFERENCES

Provide a list of documents referenced elsewhere in this document and/or
other documents that were used during research or may help the reader
understand the feature.

Identify each document by title, report number (if applicable), date and
publishing organization.

If possible, specify the sources from which the references can be obtained
Click here to begin typing.
DBMS Authentication106763433
Page 15 of 44
1.4 NOTEWORTHY ISSUES
Since the DDS is an evolving representation of the design (a "living document"),
this section is used to keep track of issues that arise during the project life cycle
and items that need special attention. If you add a FIX_ME or comment similar
to “need to do something about blah here” to the code, you should NOTE: the
issue here.
Open issue regarding OpenROAD and what changes might be necessary, or
desirable, to support dbauth connections cleanly.
Star support of mixed dbauth/non-dbauth environments is being punted for now,
not sure what can or should be done there.
Actian Director probably needs to know whether target installation supports new
user options. Should this be something in iidbcapabilities or equivalent? Or
does bumping the SQL Level suffice?
This spec does not attempt to describe any changes to Visual DBA. It is unclear
whether VDBA should be touched or left alone.
It would be nice to add an additional string field to the iiusers table (long_name or
description or some such name). This has not been made part of the spec. In
addition to the feature creep issue, one then has to ask whether description
should be added to iiusergroup and iirole as well. If time permits however,
adding a description column will be considered.
DBMS Authentication106763433
Page 16 of 44
2 ARCHITECTURE OVERVIEW
2.1 HIGH LEVEL DESCRIPTION
2.1.1
Overview of existing authentication mechanisms
Ingres and Vectorwise (up to version 10.1 and 2.5 respectively) support
traditional authentication options. They are:
1. Operating System authentication;
a. Local users connect without needing a password (essentially
Single Sign On). NOTE: does not allow user impersonation unless
either the impersonator is an admin/super user OR the
impersonator is logged into the operating system as the required
user.
b. Remote users provide their operating system username and
password, usually via a vnode. NOTE: does allow user
impersonation but requires OS users to be managed as well as
DBMS users.
2. Installation passwords
a. Installation administrator sets up a vnode that use a secret
installation password. When users make use of this vnode (the
password is hidden from the users) to connect remotely, they are
authenticated by the operating system and the installation
password. The session user is the logged-in OS user on the
client. NOTE: allows user impersonation as long as the client has
the user as an OS user, and the impersonator can log in as that
user on the client.
3. Kerberos support
a. Allows SSO (even remotely) and includes encrypted network
traffic to remote servers. The session user is the Kerberos
principal.
DBMS Authentication106763433
Page 17 of 44
The existing authentication architecture is based on the GCN process performing
ALL user authentication. The DBMS simply receives a user name in the
connection request, and that user (presuming it to be a valid Ingres user)
becomes the session user.
After the initial connection, the client may also send a DBMS password as part of
the modify-association (GCA_MD_ASSOC) message. This password is sent in
cleartext, and is compared with the DBMS password defined by the iiuser record
in iidbdb. (The iiuser password is stored as a one-way hashed value.)
2.1.2
The DBMS Authentication Mechanism
The new DBMS-authentication (dbauth) mechanism offloads the user
authentication from the GCN, instead passing the GCA_REQUEST username
and password to the DBMS as part of the connect request. The connect request
will also indicate “unauthenticated”, so that the DBMS knows that it must do user
and password checking. If the user is a valid Ingres user, and the password
hashes to the stored iiuser password, the connection succeeds. The dbauth
mechanism makes no reference to OS user or password, so it is possible to have
DBMS users that are not valid OS users. The password sent with the
GCA_REQUEST message is encrypted over the wire, so it is not visible in
cleartext.
The GCN will not defer authentication to the DBMS unless the DBMS server says
that it can handle it. There will be a new configuration parameter to turn dbauth
on or off, per DBMS server. Dbauth may only be configured at the server level,
not per database. An example of where per-server dbauth configuration may be
useful is with Enterprise Access (gateway) as follows:

Some users deploy gateways for both Oracle and Microsoft SQL Server
(MSSQL). Typically customers use the default authentication mechanism
for each back end; for MSSQL this means OS authentication, for Oracle
this means DBMS authentication. The new Ingres dbauth mechanism will
allow end users to configure the Oracle gateway with dbuth to use the
secure password sent via the client vnode as a pass through to the
gateway (with the current mechanism users have to send passwords
insecurely via the “-P” flag or by storing passwords on the gateway
DBMS Authentication106763433
Page 18 of 44
machine). Conversely MSSQL users using OS authentication will want to
continue to use the original GCN auth check as the gateway passes on
user tokens (rather than passwords) to MSSQL.

Dbauth will allow gateways access to client password information; this
information has not been accessible to servers since Ingres 2.5.
There are still some situations where the GCN will perform some sort of
authentication: local connections (i.e. no username or password given with the
GCA_REQUEST), installation password connections (the session user is the OS
user on the client side), and Kerberos connections (the session user is the
Kerberos principal). For these situations, the dbauth server will not see the
“unauthenticated” flag and will perform the connection the old way, checking only
that the user is a valid Ingres user. (This satisfies the requirement that
administrative users be able to connect locally with no DBMS password.) Since
one of the purposes of dbauth is to stop sending cleartext passwords, a dbauthenabled server will not attempt to ask for or verify any DBMS password when it
received an already-authenticated connection request. Dbauth-enabled servers
will always ignore any password element (GCA_RUPASS) of the modifyassociation message.
When dbauth is active, the GCN acts purely as a pass through mechanism for
remote connection requests. One implication of this is that connection testing that
does a connect to a remote GCN (e.g. the existing netutil “test vnode” option) will
behave differently; it will now act as a ping test; it will no longer test the vnode
authentication. Users who want to test authentication should make a database
connect test. For example, the ODBC configuration tool shipping since Ingres 2.6
tests authentication using a database connection test.
When dbauth is enabled, any GCA connection request supplying a username
and password (i.e. anything other than a purely local connection) will be
authenticated against that username and password. This allows users to
impersonate other users, assuming that they know the relevant (DBMS)
password. The exact syntax needed at the client end will depend on the
application environment, API (or API-based) vs libq. API style connections
(including ODBC, JDBC, .NET) specify the username and password in the data
source or connection request; user entry of the username and password is
entirely up to the application. Libq programs (ESQL, character 4GL,
DBMS Authentication106763433
Page 19 of 44
OpenROAD) have a somewhat more complex set of possibilities, as username
and password entry is partially handled by the Ingres library:

The program can specify the -local_system_user and local_system_password options in the connect statement. (or, for remote
connections, the equivalent remote_system_user and
remote_system_password options.) These options exist today, although
they are little known and not documented.

The program can specify a vnode (containing username and password)
as part of the database name.

The program can specify the database name using "inline" vnode syntax,
i.e. '@[user,password]::dbname' for local connections, or
'@host,port[user,password]::dbname' for remote connections.

The program can specify a new connect option -user=username which
will pass the specified user as remote_system_user, and will prompt for a
password to be sent as remote_system_password. (Note the difference
from -u username, which sends the session effective user in the
MD_ASSOC message after the connection is made. Use of -u and -user
together is allowed; the initial connect user is the -user one, and the
effective user is the -u user.) For completeness, the password can be
specified inline as well, as -user=username,password.
The new -user option is fundamentally an exec sql connect option, but the intent
is to add it to standard command-line tools as a command line option as well. (At
minimum, the terminal monitor accept -user on the command line.) If the -user
connect option is used, the database name must not contain any [user,password]
part. The database name can include remote host information (in the form
@host,port::dbname).
The reason for adding the -user connect and command line option is that it
enables a convenient way for libq utilities (such as the SQL Terminal Monitor) to
connect to a dbauth server, without the awkwardness of the inline vnode syntax 
which also exposes the password on the command line to utilities such as ps.
The existing -P option is unavailing, as it sends the password with the modifyassociation rather than the connection request, and does nothing about the user
name. (As noted above, old-style DBMS passwords are ignored when
connecting using dbauth.)
DBMS Authentication106763433
Page 20 of 44
Any utility or application that wants to accept -user on the command line will have
to be changed to pass that option through to the exec sql connect options=
string. The password prompting implied by the -user connect option will be done
with the Ingres library IIUIpassword() function, which does not echo password
entry, and does "the right thing" when in character forms mode. Ingres utilities
changed to accept -user on the command line will also be changed to prohibit
simultaneous use of -P (old-style password). Please note that any libq client
application with special password entry requirements is free to collect the
password in any manner it likes, and supply it to the connect using local or
remote_system_password, or vnode syntax.
If the -user option prompts for a password, and if the SAVEPASSWORD set_sql
option has been enabled (set to 1), the password is saved and re-used if another
connect statement is executed with -user=username (ie requesting a password
prompt). The password re-use will NOT verify that the connecting user is the
same, it's up to the application to control SAVEPASSWORD appropriately. This
feature is mostly for utilities such as optimizedb which connect once to check
whether the target is an Ingres database or a gateway, and then disconnect and
reconnect using the complete command line option list.
As noted above, purely local connections by valid Ingres users succeed with no
password prompt. In order to support situations where a mandatory DBMS
password is desired, a new CREATE USER with-option will be added:
DBMS_AUTHENTICATION='REQUIRED' or 'OPTIONAL'
With the default being 'OPTIONAL'. An authentication-required user must
connect using DBMS authentication. Connection requests that are already
authenticated outside the DBMS (local connections, installation-password
vnodes, Kerberos authentication) will be rejected with an error. An
authentication-required user cannot connect to a non-dbauth server at all.
Obviously, system administration users should be defined as DBMS
authentication-optional. Users with the "security" privilege will be forced to be
DBMS authentication-optional. (Originally, only the installation owner was going
to be forced optional, but it turns out to be remarkably difficult to determine the
installation owner from within the DBMS server.)
Users defined with no DBMS password are unusable with dbauth servers except
from non-dbauth connections (local, installation-password, Kerberos). It shall be
DBMS Authentication106763433
Page 21 of 44
an error to create or alter a user with both DBMS_AUTHENTICATION
'REQUIRED' and no DBMS password.
Older clients that predate DBMS authentication will still work with dbauth servers,
since the only client side requirement is that the desired username and password
both be supplied with the GCA_REQUEST message. Existing clients can do this
via vnodes (defined or inline), or with the system user/system password options.
The only client side feature unavailable from existing clients will be the new
libq/esql -user connect / command line option.
A mandatory requirement is the ability to change passwords. This capability
exists, but is only available today to users with the "maintain_user" privilege;
typically, a user is not able to change his or her own password. A new DBMS
user privilege will be added: CHANGE_PASSWORD. A user with the
CHANGE_PASSWORD privilege will be allowed to change his/her own
password (but nobody else's). A user is not permitted to change the changepassword privilege unless they have maintain_user privilege.
The CHANGE_PASSWORD privilege flag within the iiuser table will be
implemented, but actually implementing the ability for a user to change their own
password will be a stretch goal of the project.
Expiry date partially satisfies nice-to-have requirement:
Administrators should be able to set password rules such as minimum
length, minimum complexity requirements, expiration time, number of
failed login attempts, etc.
We do not have support for any of the other items in the list (for example,
“minimum length”), however this logic could be added to the DBMS in a later
project after we have experience with DBMS authentication out in the field.
The only nice-to-have requirement from
http://community.actian.com/wiki/Database_Authentication missing is:
Administrators should be able to use SSL key verification.
SSL certificate support requires SSL/TLS support; this is outside the scope of
this project, and in any case, SSL support is not directly related to DBMS
authentication.
NOTE: query text is plain text (unless using Kerberos), this includes passwords
in CREATE/ALTER user. This will not change. SSL support would deal with this.
DBMS Authentication106763433
Page 22 of 44
NOTE: DBMS Users are global to the installation; e.g. the user “fred” is known to
all databases (but may not have permission in all databases) and is the same
fred in all databases. This will not change with dbauth.
When security auditing is enabled, dbauth authentication failure will be audited in
the same way that an invalid DBMS user is audited today.
2.2 SQL LANGUAGE CHANGES
One additional (optional) WITH option and one additional PRIVILEGE=() option
will be added to the Ingres CREATE and ALTER USER and PROFILE
statements.
The new WITH option is:
DBMS_AUTHENTICATION = {'REQUIRED' | 'OPTIONAL'}
This option specifies whether the user can connect via any mechanism other
than DBMS authentication. If 'REQUIRED', only connect requests specifying the
user and password in the GCA_REQUEST, to a dbauth server, can succeed;
other connections including purely local connections will fail. No "security" user
can be defined as DBMS_AUTHENTICATION='REQUIRED', which includes the
installation owner and the catalog owner $ingres. The default is OPTIONAL.
Upon upgrade, existing users convert to OPTIONAL.
The new privilege is:
CHANGE_PASSWORD
This privilege can be specified anywhere that a privilege-list is used:
PRIVILEGE= or DEFAULT_PRIVILEGE=. The CHANGE_PASSWORD privilege
allows the user to change his/her own password with ALTER USER. Existing
users will not receive the privilege during catalog upgrade, since the privilege
does not exist currently. Note that the ability to actually change one's password
with ALTER USER is a stretch goal.
DBMS Authentication106763433
Page 23 of 44
2.2.1
Language changes to Ingres/Star’
Will the language changes be implemented in Ingres/star? If not why not?
None, Star does not support CREATE USER.
2.2.2
Language Changes to ABF
Will the language changes be implemented in ABF? If not why not?
Connections to ABF and imaged 4GL applications are governed by the libq/esql
rules listed in 2.1.2, as ABF/4GL uses libq for database connections. Depending
on where 4GL CONNECT statement options are validated, the new -user
connect option may need to be added to the 4GL runtime. 4GL will have to be
checked to see if it supports and validates the CREATE/ALTER USER options.
No other language changes.
2.2.3
Language Changes to Database Procedures
Will the language changes be implemented or be functional inside database
procedures? If not why not?
None.
2.2.4
Language Changes to Embedded SQL pre-compilers
Will the language changes be implemented in the embedded SQL Precompilers? If not why not?
The ESQL grammar will need to be checked to see if it validates
CREATE/ALTER user with-options; if it does, the new
DBMS_AUTHENTICATION option and CHANGE_PASSWORD privilege will
have to be supported.
2.2.5
Effects on dynamic SQL
Will the language changes work in dynamic SQL? If not why not?
None
DBMS Authentication106763433
Page 24 of 44
2.3 IMPLICATIONS FOR GCA
Is there anything about this feature (including language or data-type changes)
that will require a new GCA message type or have any other affect on GCA?
No changes to GCA, existing GCA protocol will be used.
2.4 CONNECTION PARAMETERS
No change to API or API-based connection parameters. As noted above, the
DBMS-password connection parameter is meaningless and ignored when
connecting to a dbauth server, but the parameter will still be accepted.
ESQL (libq) will have the -user option added to the EXEC SQL CONNECT
OPTIONS= string. This is a convenience option aimed at making dbauth
connections from ESQL programs easier and more consistent.
Syntax details for -user:
-user[=username[,password]]
Pass username as the "remote system user" and password as the "remote
system password", ie the dbauth user and password. If password is omitted, the
ESQL runtime will prompt, using IIUIpassword (the same routine used by the -P
option today). If user is omitted, the logged-in OS effective user (geteuid) will be
used. Note that if IIUIpassword is unsuitable, the application is free to acquire a
username and password in any way it likes, and pass them using vnode syntax
or user-password connection options.
If -user is specified, the database name must not include any [user,password]
syntax.
The -user option is supported in the EXEC SQL CONNECT OPTIONS= string.
The exact same syntax will be used on the command line, for those utilities that
support it.
Note: for local connections, the local_system_user (password) and
remote_system_user (password) are essentially equivalent. (They can be
different if the connecting program is a "trusted" server, i.e. a Star server, but
DBMS Authentication106763433
Page 25 of 44
we're considering client connections here.) For remote connections, the values
sent to the remote server are the remote_system_user and password. The -user
option will always send the user and password as the remote user / password
since that will do the right thing in all scenarios.
2.5 LANGUAGE, UNICODE AND INTERNATIONALIZATION ISSUES
Is there anything about this feature that causes it to have unique characteristics
or testing requirements when implemented for the international market and
support for international or multi-byte character sets including Unicode (UTF16 or
UTF8)?
No changes.
2.6 IMPLICATIONS FOR INGRES/STAR
Does this feature have any implication for Ingres/Star? If so what are they?
Star servers can be defined as dbauth enabled. A dbauth-enabled Star server
will remember the password included with an unauthenticated (i.e. dbauth)
connection request, and in turn supply that password to any LDB's that that
session connects to. This implies that the LDB should also be dbauth. There
does not at present appear to be any good way to mix dbauth and non-dbauth
LDB's, other than by making the DBMS and relevant OS passwords the same.
2.7 IMPLICATIONS FOR DBA TOOLS
Does the feature have any implications for the DBA tools such as copydb,
auditdb, rollforwarddb, verifydb? Would a new verifydb option be useful?
Tools will need to be updated for:
1. CREATE/ALTER USER update (for new privileges)
2. Test connections will need to be updated due to change in behavior for
netutil test. In netutil, either two "Test" function keys are needed, or the
existing Test should dispatch to a submenu offering Host Connection and
DB Connection. Note, this is a stretch goal.
DBMS Authentication106763433
Page 26 of 44
3. Command line utilities will need to accept the -user option on the
command line. (Required for terminal monitor, stretch goal for everything
else.)
4. VDBA?
Actian Director will need to be updated to support the new CREATE USER
options, and possibly to address the semantic change in "connection test".
Visual DBA probably has something in it that needs attention, however it's not
clear whether we want to "fix" it, take out whatever would otherwise need to be
changed, or just leave it alone.
2.8 NEW IMA/MIB OBJECTS
Did you add any IMA objects as part of this feature? Are there any that would be
useful that perhaps you didn’t add because of lack of time?
None
2.9 NEW TRACE POINTS
Trace points should be avoided in favor of IMA objects. If you added any trace
points detail them here with an explanation of why it was not suitable for an IMA
object.
No new trace points are envisaged.
2.10 CATALOG ALTERATIONS
Does the feature add or alter the Ingres catalogs, either DBMS catalogs, frontend catalogs, or iidbdb catalogs? If so, fill in the details here and be sure to
update the document containing the catalog spec, which can be found here:
http://community.ingres.com/wiki/Ingres_Catalogs
User catalog iiuser will be changed to support the DBMS_AUTHENTICATION
option and CHANGE_PASSWORD privilege. Fortunately, there are a number of
existing privilege bits formerly used for B1 security that are no longer used; two
of these will be re-purposed and the rest forcibly cleared for future use.
DBMS Authentication106763433
Page 27 of 44
2.11 IMPLICATION FOR GATEWAYS
Does this feature have any implications for the Ingres gateways? Do any SQL
language changes need to be considered for implementation in gateway
products?
Enterprise Access Gateways would like to make use of this feature; gateway
team should be involved when discussing GCN registration mechanism.
2.12 IMPLICATIONS FOR DATABASE DRIVERS
Does this feature have any implications for any of the database drivers such as
ODBC, JDBC, Python, PHP, Ruby, etc? Do any SQL language changes need to
be considered for implementation in these drivers?
Drivers should already be using the (remote) username/password connection
options. May need to review drivers for local usage when overriding (i.e.
impersonating) the username and password as a non-super user. E.g. in ODBC.
JDBC will need to be tested with local user (with new name/password specified)
and DBMS_AUTHENTICATION='REQUIRED' set for that user.
2.13 IMPLICATIONS FOR OPENROAD
Does this feature have any implications for OpenROAD? De sure to mention any
changes to ADF that are necessary to implement this feature, they often impact
OpenROAD. Do any SQL language changes need to be considered for
implementation in OpenROAD
OpenROAD will need to change to support the CREATE/ALTER USER changes.
It may also be desirable to support the -user connection option. Needs someone
OR-knowledgeable to weigh in!
2.14 DESIGN LIMITATIONS AND ASSUMPTIONS
This section should list current limitations and assumptions made in the design.
A basic assumption is that Ingres users are defined installation-wide, not perserver or per-database.
DBMS Authentication106763433
Page 28 of 44
The current design does not attempt to solve or deal with dbauth-enabled Star
operating in mixed dbauth / non-dbauth environments. While the exact behavior
is will defined, the results may or may not be useful.
2.14.1 Dependencies
Does this feature depend on any external functionality (such as an XML parser,
or some other similar piece of code that does not belong to Ingres)? Does this
feature depend on another feature that will be, or has been coded in this release
of the product? Describe the dependency.
None.
2.15 PLATFORM SPECIFIC ISSUES
None.
2.16 PRODUCT INTERACTION
Does this feature cause any changes in the way that Ingres products interact with
each-other other than already detailed in the above sections? Are there certain
products that will/will no work with this feature (this is more relevant to tools such
as VDBA and new middle-ware servers)?
Actian Director may have to be at least somewhat aware of the target installation
capabilities so as to send / not send DBMS_AUTHENTICATION option or
CHANGE_PASSWORD privilege in CREATE or ALTER USER statements.
2.17 PATENT INFORMATION
If there is any technology being developed for this feature that could be
considered for a patent, NOTE: the information here.
N/A
DBMS Authentication106763433
Page 29 of 44
3 EXTERNAL SPECIFICATION
3.1 USER PERSPECTIVE
In this section, the focus is on the tasks that a user will perform with this feature.
Describe what the feature does and how it works form a user perspective. Focus
on how it is used to perform the function described in the high level description.

Provide screen shots if appropriate
Once Ingres is installed, the installation owner should be able to create a user,
e.g.:
> sql iidbdb
CREATE USER fred WITH PASSWORD = 'secret';
\p\g
\q
Assume that dbauth is turned on for the following examples.
A user logged in locally (on the server machine) can connect as before,
assuming that the user is defined with dbms authentication optional:
sql dbname
If the user is defined with dbms authentication required, the connection attempt
fails. Note that in the successful case, even if the user has a dbms password, no
password prompt occurs, nor any dbms password validation.
DBMS Authentication106763433
Page 30 of 44
The user may also connect, either as themselves or as some other Ingres user,
using dbms authentication. Since “sql” is a libq program, the -user option can be
invoked, or the local-vnode syntax used:
sql -user dbname
sql -user=fred dbname
sql '@[fred,secret]::dbname'
In the first two examples, the user is prompted for the password before the
DBMS connection is made. The first example connects as the logged-in OS
user, the second connects as user 'fred'. In the third example, the password is
entered on the command line. For the last two examples, user fred need not be
an OS user.
As a side note, if dbauth is NOT enabled at the server end, the last two examples
still work; except that fred would then have to be an OS user, and the password
would have to be fred's OS password. If fred had a dbms password defined, with
dbauth off, the server will request a password prompt for the DBMS password.
(Thus, the -user=fred example might get two password prompts if dbauth is off.)
If connecting to a remote host using dbauth, either a vnode or inline vnode
syntax can be used:
sql vnode::dbname
(user, password in the vnode)
sql '@host,VW[fred,secret]::dbname'
(inline)
sql -user=fred @host,VW::dbname (prompts for password)
The effective-user capability does not conflict with the -user option. As an
example, if user fred has DB_ADMIN privileges for the database, he can connect
and authenticate as himself, but then run the session with a different effective
user:
sql -user=fred -u ralph dbname
In this example, the user is prompted for a password (which will be user fred's
password), and the user (fred) and password are authenticated by the DBMS.
Once the session is established, the effective user (ralph) is set.
DBMS Authentication106763433
Page 31 of 44
API and API-based connections (ODBC, JDBC, .NET) all have a directly
specified username and password that correspond directly to the
GCA_REQUEST username and password. Those clients would not see any
change, other than having the user/password authenticated by the DBMS against
the iidbdb user/password instead of by the GCN against an OS user/password.
As mentioned before, any DBMS password sent by an API or API-based
application to a dbauth server would be ignored.
3.2 INSTALLATION AND ADMINISTRATION PERSPECTIVE
Include any special installation and setup tasks, system parameters or other
preparations that are necessary prior to use. Describe the steps needed to
setup and get the component going and any ongoing administration that will
need to be performed if relevant. List all configuration parameters that apply to
this feature here.
The installers will ask whether to install with dbauth turned on or off. The
relevant configuration parameter will be
ii.hostname.dbms.configname.dbms_authentication: ON/OFF
The dbms.crs default will be OFF.
The iii.$.secure.user_password parameter will be deprecated and ignored. (That
parameter allowed an installation to prevent the creation of DBMS passwords,
which is of dubious use in any case, and is untenable with dbauth on.)
3.3 MIGRATION ISSUES
Describe any special steps required to migrate from existing versions
Ingres/OpenROAD to this version that arise because of this feature. Does this
feature have any new catalogs or other implications for upgradedb?

Is the component going to be backward compatible?

Can this version co-exist with an older version?
Feature is expected to be backward compatible, that is, old remote client should
work with new (remote) dbauth enabled servers assuming that the DBMS
password defined in iiuser is compatible with the vnode password.
DBMS Authentication106763433
Page 32 of 44
When an existing installation is upgraded, existing users will be set to
dbms_authentication=’optional’, and will not get the change_password privilege.
3.4 SECURITY IMPACT
Does anything about the function need securing? Could it do any damage?
Could it cause the display of sensitive information?
Does the implementation methodology do anything that produces a potential
security exposure, such as run as root or Ingres (if this is an application)?
Security is paramount in this project as security is the main focus!
No changes are expected to the way we handle passwords as they are between
the client and the server (the biggest exposure point of passwords to external
observers). That is, the traditional username password exchange will be
unmodified; usernames sent as plain text, passwords will be encrypted as they
are today.
The server side implementation will make some effort to wipe memory areas
holding passwords. Any password held for long-term storage (such as in Star,
for LDB connects) will be obscured if not encrypted while in memory. The goal is
to avoid casual password collection in the event of unintended access to the
server memory image (core dump, etc).
DBMS Authentication106763433
Page 33 of 44
4 INTERNAL SPECIFICATION
4.1 ESTIMATED TASKS AND EFFORT
Estimate the engineering effort to code and test the component ready for hand
over to QA and Technical Writing. If it is a large function, break it up into smaller
“function points” and estimate each one. For large projects, filling out the table
below and should help but is not required. Estimates should be effort to code
complete; that is engineering effort assuming 100% of an engineer’s time is
used, which will not normally be equal to elapsed time for the project. Estimates
should include time to:

Code the feature and all of the error checking required for the feature
(error checking may be up to 50% of the code in the DBMS)

Test your code and make corrections

Write and post an integration plan (or more than one for large projects)

Run HandoffQA for each proposed submission and check the results
As a guide, an experienced engineer who already knows the code will normally
write and sanity test about 100 lines of code per day; engineers with less
experience or those that are new to the code will write less. Factor about 20% of
the time it took to code for final testing and fixes. Look at existing modules to help
make an estimate of the number of lines of code required. Tasks should normally
be submitted as they are sane and complete, so the formula might be something
like:
Time for task = (no_of_lines / 100) + 2 days for IP and HandoffQA
Total time = Sum (time for all tasks) + 20% for overall testing and fixes
Click here to begin typing
Task
Effort
(persondays)
Assigned to
Done
(yes/no)
Tested
(yes/no)
Description of task
DBMS Authentication106763433
Page 34 of 44
Total days
TOTAL
-
-
-
4.2 PROGRAMMING
List programs and modules written, changed or deleted. Initially this will be a
first pass estimate of what needs to be changed, it will likely change during the
course if the project. The version of this document at code complete will contain
the modules or programs that actually changed.
GCA changes to pass GCA_REQUEST password thru to server are already
done.
Server side:

Implement new iiuser privs for DBMS_AUTHENTICATION,
CHANGE_PASSWORD. Add syntax to create/alter user parsing. See if
same needed in profile row, at the very least make sure that profiles don't
interfere.

Read and store dbms_authentication config parameter.

Collect password from GCA_LISTEN request, store it someplace until
scs_initiate does user validation, then validate the password. Implement
dbauth-required check. Toss password after validation unless Star; Star
has to put it somewhere with session lifetime.

Record fact of dbauth connect, ignore GCA_RUPASS if so.

Star: pass gca_password to LDB if dbauth session.

(stretch) Implement ALTER USER PASSWORD= for change-password
enabled users. This will probably involve a special bypass for the alter
user privilege check against maintain_users, which is why it's stretch.
In libq : utils/ui : tools:

Add -user to connect option processing in libq (libqgca).

Teach tools (as many as possible, tm minimum) about -user on the
command line. Just need to accept/pass the option, don't need to
validate it; exec sql connect will do the checking and prompting.
Command line option checker needs to enforce -user interactions (no -P,
DBMS Authentication106763433
Page 35 of 44
no [user,pwd] or does that go in exec sql connect, or both?
(Implementation will choose.)
Elsewhere / misc:

CREATE/ALTER USER options in esql, 4GL parsers.

Upgradedb work for iiuser: clear old B1 junk, set new option defaults.
Bump the iidbcapabilities SQL level, and/or add new capability indicating
that new user privs exist (see Noteworthy Issues).

Add dbms_authentication config param to cbf, all the usual crs things
(including cbf help).

Actian Director changes to support new user options and to deal with oldversion compatibility.
4.3 COMPATIBILITY LIBRARY INTERFACE CHANGES
Describe any changes made to the compatibility library interface. Any changes
described here should be copied to CL platform reviewers for approval before
changes are made, and the CL spec should be updated to reflect the new
interface. Current platform reviewers are:
Darren Horler – VMS
Viktoriya Driker - Windows
Bob Bonchik, Alex Hanshaw – UNIX
Alex Hanshaw - Linux
None envisioned at present.
4.4 INTERFACE
How do other components that are external to the design interact with this
component? Describe methods and rules of interaction.

Communication protocols; is GCA affected? Other?

Changes of facility call interfaces in the DBMS (e.g. is dmf_call changed?)

Changes to the interface of non static functions
DBMS Authentication106763433
Page 36 of 44

New error codes or error conditions that will be logged or propagated up the
stack to other functions. Has the error handling for those functions been
updated?
GCA_LISTEN reply will now contain a password and a new "unauthenticated"
flag. (already done)
4.5 BUILD IMPLICATIONS
Does this feature require any special jam rules? Did it require any changes in jam
MANIFEST files? Any new build targets? Any other build alterations?
4.6 UI RESOURCE/PROPERTIES FILES
This section is largely relevant to GUI applications like OpenROAD and can be
removed for DBMS features.
Provide the names of the files required by the UI and Messages
File Name
Byte Count
Word Count
Format
Comments
4.7 BITMAP RESOURCES
This section is largely relevant to GUI applications like OpenROAD and can be
removed for DBMS features.
Provide the bitmap resources.
File
Comments
DBMS Authentication106763433
Page 37 of 44
4.8 ICON FILES
This section is largely relevant to GUI applications like OpenROAD and can be
removed for DBMS features.
Provide the icon files used.
File
Comments
Release note
System
requirements
4.9 PICCOLO CHANGE NUMBERS
Provide piccolo change numbers for changes made for this feature. This will be
filled in after the fact and should include change numbers for propagations of the
same change to other branches if appropriate
Change Number
Submitted to (code-branch)
Submission date
main
DBMS Authentication106763433
Page 38 of 44
5 IMPACT AND DOCUMENTATION SUMMARY
The estimates in this section are approximate and are intended to give other
groups such as Technical Writing, Services, Support and QA an idea of the
impact this change will have.
Need to document new feature in new features/readme guide/section.
Need to document CREATE/ALTER USER additions.
Need to document config option for enable/disable dbauth.
Need to document @[name,pass]::dbname syntax.
Need to better and more fully document EXEC SQL CONNECT OPTIONS=
options (currently one is referred to the command reference for the sql
command!)
Need to document new -user connect / cmdline option.
5.1 PRODUCT/COMPONENT IMPACTS
5.1.1
Entities
List the tools, commands, reports and messages that are impacted by the
development of the module/function. Use the table below to summarize these
changes; you can refer to other sections for details.
Entity
New
Modified
Comments
Tool
Commands
Messages
Help Modules
5.2 DOCUMENTATION
List the existing end-user documentation that is affected by modules changes,
and how it is affected. Be as specific and thorough as possible.
DBMS Authentication106763433
Page 39 of 44
MANUAL
CHANGES NEEDED
Estimated
# of Pages
Installation Guide
Database Administrator Guide
System Administrator Guide
Connectivity Guide
SQL Reference Guide
Command Reference Guide
Migration Guide
DBMS Authentication106763433
Page 40 of 44
6 QUALITY ISSUES
Look at the component from the QA point of view. Suggest any special tests
that will stress the component. Think how to make the component NOT work
and what special tests should be performed on this component. This is a
guideline to the QA testing procedures.
6.1 UNIT TESTING SUMMARY
Testing individual functions or subroutines in isolation is called unit testing. Unit
testing in some cases requires the developer to use stubs and drivers. Describe
the unit testing you did in these sections. Attach all unit tests to the wiki page for
this feature so that they are available to QA.
6.1.1
Unit Testing Description
List and unit testing planned or done.
Click here to begin typing
6.2 HANDOFFQA IMPACT
In this section you should document expected or observed diffs in HandofQA
caused by the feature as well as other things that impact HandoffQA; should any
new tests be added to HandoffQA for this feature to prevent regression?
6.3 TESTING RECOMMENDATIONS
Suggest other additional function tests that are necessary. Special test
requirements, for example: the security levels, hardware or software
configurations, code page and multiple code pages, multi-system issues. NOTE:
anything that cannot be tested in a lab and which might require field tests. What
can go wrong? How are these situations dealt with?
Testing scenarios should be reasonably obvious. Some specifics to test:

New client using -user connecting to old installation, or to non-dbauth
server. (Should work with password being the OS password, assuming
the user is a valid Ingres + OS user.)
DBMS Authentication106763433
Page 41 of 44

ODBC / JDBC / .NET connections to a non-OS user using dbauth.

Various combinations of supplying / omitting password when connecting
to authentication-required / optional user in a dbauth server.

Verify that local connection to auth required user in dbauth server fails.

Verify that old style DBMS password is ignored by dbauth server (dbms
password conn parameter, or -P option for command line tools). Note
that it's OK for the password prompt to occur, not OK for the server to
ever reject a connection because of it.

Verify basic operation of dbauth Star with dbauth Ingres LDB servers.

Might be useful to experiment with dbauth Star and non-dbauth LDB
server such as a MS gateway to make sure it works as long as
passwords are compatible.
6.4 REGRESSION RISK ASSESSMENT
What would be the implications of failure in the component? Is the code
complex? What is the potential for destabilizing existing functions?
What other areas of the product/component interact with this module?
Unexpected code de-stabilization is unlikely because the code changes are
relatively small and localized. The greatest risk is that the spec has overlooked
something important and that we are painting ourselves into a corner somehow.
6.4.1
Backward Compatibility Issues
Is there anything that should be tested for backward compatibility? Does this
feature affect how a down-rev client connects the current version of the DBMS?
Did the GCA protocol level change? Is upgradedb required?
No problems expected, but this will need to be tested! E.g. Ingres 2.6 client
against a new dbauth server.
DBMS Authentication106763433
Page 42 of 44
7 PACKAGING AND INSTALLATION IMPACT
Indicate any special packaging or installation requirements. Detail what the
packaging and installation requirements, if any, will be. Detail any new files that
are required, remember they should be added to the manifest, you are
responsible for doing this as part of the project.
No change to packaging, but installer/setup scripts may prompt for default
authentication mechanism (with suitable wording), for example:
Authentication mechanism for server: DBMS Authentication (default) |
Traditional Ingres or possibly Operating System Authentication
(traditional)
Whilst individual servers can be configured, it makes sense for the installer to
treat this as a global setting. Individual server dbauth variance is unlikely to be
useful with DBMS servers; it's likely to be more common with gateways, which
are not installed in the same package as the DBMS.
DBMS Authentication106763433
Page 43 of 44
8 SUPPORT IMPACT
Detail any diagnostics or trace facilities built in to the component including new
IMA objects, trace points, or other build time or run-time diagnostics. NOTE:
anything that could be made into a good supportability tool. NOTE: components
that are:

Difficult to diagnose (for example: no tracing facility, dependent on specific
timing)

Difficult to service
Include workarounds where appropriate.
No new diagnostics or trace points are envisioned. Existing GCA tracing
capabilities should suffice.
8.1 EXAMPLES AND TESTS
Detail any example or test code that you wrote during the development of the
feature that may be useful to help support, QA, or customers to understand the
feature or useful to QA for testing. Attach all example and test code or details to
the wiki page for this feature
DBMS Authentication106763433
Page 44 of 44