Understanding DB2 under z/OS Client/Server Authorization

Libref Connections

When you use the DB2 interface, you can enable each client to control its own connections using its own authority—instead of sharing connections with other clients—by using the DB2 Recoverable Resource Manager Services Attachment Facility (RRSAF). See DB2 Attachment Facilities (CAF and RRSAF) for information about this facility.

When you use SAS/ACCESS Interface to DB2 under z/OS with RRSAF, the authorization mechanism works differently than it does in Base SAS:

In Base SAS, the SAS server always validates the client's authority before allowing the client to access a resource.
In SAS/ACCESS Interface to DB2 under z/OS (with RRSAF), DB2 checks the authorization identifier that is carried by the connection from the SAS server. In most situations, this is the client's authorization identifier. In one situation, however, this is the SAS server's authorization identifier. A client can access a resource by using the server's authorization identifier only if the client uses a libref that was predefined in the server session.

In this next example, a user assigns the libref SRVPRELIB in the SRV1 server session. In the client session, a user then issues a LIBNAME statement that makes a logical assignment using the libref MYPRELIB, and the user specifies the LIBNAME option SERVER=srv1. The client can then access resources by using the server's authority for the connection.

In the server session

libname srvprelib db2 ssid=db25;
proc server id=srv1;
run;

In the client session

libname myprelib server=srv1 slibref=srvprelib;
proc print data=myprelib.db2table;
run;

In this example, because the client specifies a regular libref, MYDBLIB, the client has its own authority for the connections.

In the server session

libname myprelib db2 ssid=db25;
proc server id=srv1;
run;

In the client session

libname mydblib server=srv1 roptions='ssid=db25' rengine=db2;
proc print data=mydblib.db2table;
run;

In this table, SAS/SHARE clients use LIBNAME statements to access SAS libraries and DB2 data through the server. In this description, a logical LIBNAME statement is a statement that associates a libref with another libref that was previously assigned.

Librefs and Their Authorization Implications

Client Session
libname local v8 'SAS.library' disp=old; libname dblocal db2 connection=unique;	These statements execute in the client session. these are local assignments. The authority ID is the ID of the client.
libname remote 'SAS.library' server=serv1 rengine=v8 roptions='disp=old'; libname dbremote server=serv1 rengine=db2 roptions='connection=unique';	These statements execute in the server session on behalf of the client. Libref Remote is a Base SAS engine remote assignment. Libref DbRemote is a DB2 engine remote assignment. In both cases, the authority ID is the ID of the client.
Server Session (id=serv1)
libname predef v8 'SAS.library' disp=old; libname dbpredef db2 connection=unique;	Because librefs PreDef and DbPreDef are defined in the server session, they can be referenced only by a client using a logical LIBNAME statement. There is no authority ID because clients cannot access these librefs directly.
Logical Assignments - Client Session
libname alias (local); libname dbalias (dblocal);	These statements create aliases ALIAS and DBALIAS for librefs Local and DbLocal, which were assigned in the client session above. The authority ID is the ID of the client.
libname logic server=serv1 slibref=predef; libname dblogic server=serv1 slibref=dbpredef;	These statements refer to librefs PreDef and DbPreDef, which were assigned in the server session above. Libref Logic is a Base SAS engine logical assignment of remote libref PreDef. The authority ID for libref Logic is the ID of the client. Libref DbLogic is a DB2 engine logical assignment of remote libref DbPreDef. The authority ID for libref DbLogic is the ID of the server.

For the Base SAS engine Remote and Logic librefs, it is the client’s authority that is verified. (This is true for all Base SAS engine assignments.) DbRemote and DbLogic DB2 engine librefs refer to the same resources. However, it is the client’s authority that is verified for DbRemote, whereas it is the server’s authority that is verified for DbLogic. When using the DB2 interface, you can determine whether to use the client’s authority or the server’s authority to access DB2 data.

Non-Libref Connections

When you make connections using the SQL pass-through facility or view descriptors, the connections to the database are not based on a DB2 engine libref. A connection that is created in the server, by using these features from a client, always has the authority of the client, because there is no server-established connection to reference.

This example uses the SAS/SHARE Remote SQL pass-through facility. The client has its own authority for the connections.

In the server session:
```
proc server id=srv1;
run;
```

In the client session

proc sql;
   connect to remote (server=srv1 dbms=db2 dbmsarg=(ssid=db25));
   select * from connection to remote
      (select * from db2table);
   disconnect from remote;
quit;

This example uses a previously created view descriptor. The client has its own authority for the connections. The PreLib libref PreLib that was previously assigned and the client-assigned libref MyLib have no relevant difference. These are Base SAS engine librefs and not DB2 engine librefs.

In the server session

libname prelib V8 'SAS.library';
proc server id=srv1;
run;

In the client session

libname prelib server=srv1;
proc print data=prelib.accview;
run;

In the client session

libname mylib 'SAS.library2' server=srv1 rengine=v8;
proc print data=mylib.accview;
run;

Known Issues with RRSAF Support

SAS/SHARE can use various communication access methods to communicate with clients. You can specify these through the COMAMID and COMAUX1 system options.

When you use XMS (Cross Memory Services) as an access method, DB2 also uses XMS in the same address space. Predefining DB2 server librefs before starting PROC SERVER can result in errors due to the loss of the XMS Authorization Index, because both SAS and DB2 are acquiring and releasing it. When using XMS as an access method, use only client-assigned librefs on the server.

This problem does not occur when you use the TCP/IP access method. So if you use TCP/IP instead of XMS, you can use both client-assigned (client authority) and server-preassigned (server authority) librefs. You can also use either access method if your connection is not based on a libref (client authority).