Database 2 CISB314

Assignment 1
Section 1A

Yageswaran a/l Ramar SW087656

Satisswaran a/l Virasagaram SW087643
Uthayahselvan a/l Uthayasurian IS091289
IBM DB2

Authentication
DB2 authentication controls the following aspects of a database security plan:
Who is allowed access to the instance and/or database
Where and how a user's password will be verified
It does this with the help of the underlying operating system security features whenever
an attach or connect command is issued. An attach command is used to connect to the
DB2 instance, whereas a connect command is used to connect to a database within a
DB2 instance. The examples below walk you through the different ways that DB2 will
authenticate a user issuing these commands.
To view the authentication parameter in the configuration file:
db2 get dbm cfg
To alter the authentication parameter to server_encrypt:
C:\PROGRA~1\SQLLIB\BIN>db2 update dbm cfg using authentication
server_encrypt
C:\PROGRA~1\SQLLIB\BIN>db2stop
C:\PROGRA~1\SQLLIB\BIN>db2start
Because DB2 UDB can reside in environments comprised of multiple clients, gateways, and
servers, each of which may be running on a different operating system, deciding where
authentication is to take place can be a daunting task. So to simplify things, DB2UDB uses a
parameter in the DB2 Database Manager configuration file associated with every instance to
determine how and where users are to be authenticated. The value assigned to this
configuration parameter, often referred to as the authentication type, is set initially when an
instance is created. (On the server side, the authentication type is specified during the instance
creation process; on the client side, the authentication type is specified when a remote database
is cataloged, which is usually performed using the Configuration Assistant.) Only one
authentication type exists for each instance, and it controls access to that instance, as well as to
all databases that fall under the instance's control.
the following authentication types are available:
SERVER. Authentication occurs at the server workstation, using the security facility
provided by the server's operating system. (The user ID and password provided by the
user wishing to attach to an instance or connect to a database are compared to the user
ID and password combinations stored at the server to determine whether the user is
permitted to access the instance/database.) By default, this is the authentication type
used when an instance is first created.
SERVER_ENCRYPT. Authentication occurs at the server workstation, using the security
facility that is provided by the server's operating system. However, the password
provided by the user wishing to attach to an instance or connect to a database stored on
the server may be encrypted at the client workstation before it is sent to the server
workstation for validation.
CLIENT. Authentication occurs at the client workstation or database partition where a
client application is invoked, using the security facility that is provided by the client's
operating system, assuming one is available. If no security facility is available,
 authentication is handled in a slightly different manner. (The user ID and password
provided by the user wishing to attach to an instance or connect to a database are
compared to the user ID and password combinations stored at the client/node to
determine whether the user is permitted to access the instance or the database.)
KERBEROS. Authentication occurs at the server workstation, using a security facility
that supports the Kerberos security protocol. The Kerberos security protocol is a protocol
that performs authentication as a third-party service by using conventional cryptography
to create a shared secret key. The key becomes the credentials used to verify the
identity of users whenever local or network services are requested; this eliminates the
need to pass a user ID and password across the network as ASCII text. (If both the
client and the server support the Kerberos security protocol, the user ID and password
provided by the user wishing to attach to an instance or connect to a database are
encrypted at the client workstation and sent to the server for validation.) It should be
noted that the KERBEROS authentication type is only supported on clients and servers
that are using the Windows 2000, Windows XP, or Windows .NET operating system. In
addition, both client and server workstations must either belong to the same Windows
domain or belong to trusted domains.
KRB_SERVER_ENCRYPT. Authentication occurs at the server workstation, using either
the KERBEROS or the SERVER_ENCRYPT authentication method. If the client's
authentication type is set to KERBEROS, authentication is performed at the server using
the Kerberos security system. On the other hand, if the client's authentication type is set
to anything other than KERBEROS or if the Kerberos authentication service is
unavailable, the server acts as if the SERVER_ENCRYPT authentication type was
specified, and the rules of this authentication method apply.
Just as the authentication type for an instance on a server is set when the instance is first
created, an authentication type is usually specified at each client workstation that will
communicate with a server. Furthermore, the combination of authentication types specified at
both the client and the server determine which authentication method is actually used.
In some situations, it may be desirable to authenticate users at the server, even when no
untrusted clients will need access. In such situations, the trust_clntauth configuration parameter
of a DB2 Database Manager configuration file can be used to control where trusted clients are
to be validated. By accepting the default value for this parameter (which is CLIENT),
authentication for trusted clients will take place at the client workstation. However, if the value
for this parameter is changed to SERVER, authentication for all trusted clients will take place at
the server.

DB2 authentication types

 Types Description

SERVER Authentication takes place on the server.

SERVER_ENCRYPT Authentication takes place on the server.

Passwords are encrypted at the client
machine before being sent to the server.

CLIENT Authentication takes place on the client

machine.

KERBEROS Authentication is performed by the Kerberos

security software.

KRB_SERVER_ENCRYPT Authentication is performed by Kerberos

security software if the client setting
KERBEROS. Otherwise,
SERVER_ENCRYPT is used.

AUTHORIZATION

INTRODUCTION
DB2 authorities control the following aspects of a database security plan:
- The authority level that a user is granted
- The commands that a user is allowed to run
- The data that a user is allowed to read and or alter
- The database objects a user is allowed to create, alter, and/or drop.

Authorities are made up of groups of privileges and higher-level database manager

(instance-level) maintenance and utility operations. Of the 5 authorities available in
DB2, SYSADM, SYSCTRL and SYSMAINT are instance-level authorities. That means
that their scope includes instance-level commands as well as commands against all the
databases within the instance. These authorities can only be assigned to a group.
The DBADM and LOAD authorities are assigned to a user or group for a particular
database. This can be done explicitly using the GRANT command.
Users can determine what authorities and database-level privileges they have by
issuing the following command :

db2 get authorizations

 INSTANCE-LEVEL AUTHORITIES
Instance-level authorities are established by assigning user groups defined in the
external security facility to the associated instance-level authority parameters
(SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP, SYSMON_GROUP).

For example, if you wanted a user account called JOHN to have SYSMAINT authority,
you could put JOHN in a group called MAINT and then update the instance parameter
called SYSMAINT_GROUP to the value MAINT. Any user in the group MAINT would
then have the SYSMAINT authority. To revoke the SYSMAINT authority from JOHN,
remove him from the MAINT group or change the value of the SYSMAINT_GROUP
parameter to a new group name users in the MAINT group if they were also not a
member of the new group.
Instance-level authority parameters can be changed from the command line or from the
Control Center. For example, to change the value of the SYSMAINT_GROUP
parameter to the value MAINT using the command line, you can execute the following
command :

update dbm cfg using SYSADM_GROUP MAINT

For the change to take effect, restart the DB2 UDB instance using the following 2
commands:

db2stop
db2start

To ensure the changes have taken effect, you can view the value of the parameter by
issuing the following command:

get dbm cfg

DATABASE-LEVEL AUTHORITIES
DBADM authority is a database-level authority rather than an instance-level authority. In
summary, DBADM users have complete control over a database. DBADM users cannot
perform such maintenance or administrative tasks as:
- drop database
- drop/create tablespace
- backup/restore database
- update db cfg for database db name

However, they can perform the following tasks:

- db2 create/drop table
- db2 grant/revoke (any privilege)
- db2 runstats (any table)

DBADM users are also automatically granted all privileges to the database objects and
their contents. Since DBADM authority is a database-level authority, it can be assigned
to both users and groups. The following commands illustrate different ways in which you
can give DBADM authority.

- db2 create database test

This command gives implicit DBADM authority on the database named test to the user
who issued the command.

- db2 connect to sample

This command can only be issued by SYSADM users. It issues DBADM authority to the
user tst1 on the sample database. Note that the issuing user must be connected to the
sample database before granting DBADM authority.

- db2 grant dbadm on database to group grp1

This command grants DBADM authority to everyone in the group grp1. Again, only
SYSADM users can issue this command.

Privileges

Privilege is to execute a particular type of sql statement or to access another users object.
Examples of privileges are :
1) Connect to the database
2) Create a table
3) Select rows from another users table
4) Execute another users stored procedure

Privileges helps users to accomplish task according to their job. Privileges can be given to a user
who really requires to accomplish the task. An user can receive privilege in two different ways :
1) Privilege to insert records
2) Privilege to select, insert, update and delete

Database-level privileges
If you create a database, you are the only one who can access it as the owner or database
administrator(DBA). As a database administrator you can grand privileges to others.

Privilege Purpose

Connect Allow you to open a database, issue queries

Resource Allow you to create permanent table

DBA Allow you to perform certain additional functions

Object level privileges

Definition of Object-level privileges

Object-level privilege is a role to perform some action on a database. Examples of Object-level
privilege are SELECT, INSERT, UPDATE, DELETE, ALTER, INDEX on tables and views,
EXECUTE on procedures, functions, and packages.

Object-level access privileges

Privileges Functions

ALTER Change the definition of the object

DELETE Remove rows from the table

EXECUTE Execute a function

INDEX Create an index on a specified table

INSERT Create new objects in the table

SELECT Retrieve data from one or more tables

UPDATE Modify the attributes of the object