Databases Reference
In-Depth Information
Authentication
Authorization
Role
has access
to data?
Look up
groups or
roles
Id in
header?
Yes
Yes
Database
request
Get/put
data
Return
result
No
No
Company
directory
Log in
Return error
Database
No
Yes
Login
ok
Deny access
Figure 11.5
The typical steps to validate a web-based query before it executes within
your database. The initial step checks for an identifier in the HTTP header. If the header is
present, the authentication is done as shown on the left side of the figure. If the user ID
isn't in the HTTP header, the user is asked to log in and their ID and password are verified
against a company-wide directory. The authorization phase shown on the right side of the
figure will look up roles for a user and get a list of roles associated with that user. If any
role has the rights, the query will execute and the results are returned to the user.
In large companies, a database may need to communicate with a centralized company
service that validates a user's credentials. Generally, this service is designed to be used
by all company databases and is called a
single sign-on
, or
SSO
, system. If the company
doesn't provide an
SSO
interface, your database will have to validate users using a
directory access
API
. The most common version is called the
Lightweight Directory Access
Protocol (
LDAP
)
.
There are six types of authentication: basic access, digest access, public key, multi-
factor, Kerberos, and Simple Authentication and Security Layer (
SASL
), as we'll see
next.
B
ASIC
ACCESS
AUTHENTICATION
This is the simplest level of authenticating a database user. The login and password
are put into the
HTTP
header in a clear plain-text format. This type of authentication
should always be used with
Secure Sockets Layer (
SSL
)
or
Transport Layer Security (
TLS
)
over
a public network; it can also be adequate for an internal test system. It doesn't require
web browser cookies or additional handshakes.
D
IGEST
ACCESS
AUTHENTICATION
Digest access authentication is more complicated and requires a few additional hand-
shakes between the client and the database. It can be used over an unencrypted non-
SSL
/
TLS
connection in low-stakes situations. Because digest authentication uses a
standard
MD5
hash function, it's not considered a highly secure authentication
method unless other steps have been implemented. Using digest access authentica-
tion over
SSL
/
TLS
is a good way to increase password security.
