Manage access with trusted context

A trusted context is a database object that defines a trust relationship for a connection between the wire listener and the Db2® database.

For more information on the use of trusted context, go to Trusted contexts and trusted connections

To run requests on the Db2 database, the wire listener establishes a connection to the database with the authentication information of the wire listener proxy user. By default, all processing is done under the authorization of this proxy user.

In authenticated mode, the wire listener uses the registry file to identify application user authorizations and perhaps a context user association. If such an association is found, the proxy user establishes a connection and sets the trusted context that is based on the registry information. The database request is run with the trusted context authorization.

To enable the use of trusted context

Set using trusted context to true in the registry file, either on the listener instance level, or for a specific db (schema).
If the use of trusted context is specified, by default the application user ID is used to establish trusted context.
You can also assign a context user ID to the application user. In this case, the context user ID is used to establish trusted context.

For example, Jane, Jill and Joe are in the J-group and need the same privileges. The Db2 database user juser is authorized to run requests, and a trusted context is established for juser. With juser associated as context user in the registry file to Jane, Jill and Joe, all three user's requests run with the Db2 context user juser.

Example of creating a trusted context

The following example illustrates how to use trusted context with the Wire Listener:

Create a trusted context. A security administrator, with SECADM or SYSADM authority, is needed to create trusted context. In the following command example, a trusted context that is called CTX is created which is based on a specific connection to the host with IP address 192.168.1.101 and it can be used by db2user2 and db2user3.
```
DB2 create TRUSTED CONTEXT CTX BASED UPON CONNECTION USING SYSTEM AUTHID db2user attributes (ADDRESS '192.168.1.101')  ENABLE WITH USE FOR db2user2,db2user3 WITHOUT AUTHENTICATION
```

Run the following command example to configure the instance:

wplistener.sh register -registrationFile /tmp/register.cfg -action configureInstance -authenticate yes -accessType local -context use

Run the following command examples to configure the schemas products and orders. Both examples use contextUser db2user2 if no explicit contextUser is assigned to an individual user:

wplistener.sh register -registrationFile /tmp/register.cfg -action configureSchema -schema products -authenticate yes -context use -contextUser db2user2

wplistener.sh register -registrationFile /tmp/register.cfg -action configureSchema -schema orders -authenticate yes -context use -contextUser db2user2

Register the application users with the Wire Listener. In this example, the application users Alice and John are permitted to use the products schema, user Mary is allowed to access the order schema.
```
wplistener.sh register -registrationFile /tmp/register.cfg -action addUser -user Alice -password alicepwd -schema products -contextUser db2user2

wplistener.sh register -registrationFile /tmp/register.cfg -action addUser -user John -password johnpwd -schema products

wplistener.sh register -registrationFile /tmp/register.cfg -action addUser -user Mary -password marypwd -schema orders -contextUser db2user3 
```
Note: The schema products is associated with contextUser db2user2. So, without an explicit assignment, Alice's requests is still executed with db2user2, as will John's. However, if the contextUser for products is changed to db2user4, then Alice's requests are executed with db2user4, while John's still use db2user2.

Run the following command example to start the Wire Listener:

wplistener.sh -start  -mongoHost localhost -mongoPort 27111 -userid db2user -password passw0rd -debug  -registrationFile /tmp/register.cfg -logPath /tmp/wllog -host 192.168.1.101:50000 -dbName jsondb

Run the application. After the wire listener is started, you can run the Mongo Client or Mongo applications. In the following Mongo Client example, if you try to find the employee collection from the products schema without authentication, you get an error. You first need to authenticate as user 'Alice' or 'John' to gain access to the collections under the products schema.
```
$mongo –host localhost –port 27111
connecting to: localhost:27111/test
> use products
switched to db products

> db.employee.find()
{ "errmsg" : "unauthorized", "ok" : 0 }

> db.auth("Alice", "alicepwd")
1

> db.employee.find()
{ "_id" : ObjectId("528d5402c841086421000001"), "name" : "Joe", 	"age" : 50 }
```

For more information, go to Establishing an explicit trusted connection and switching the user ID