Using Proxies

Considerations for using proxies.

Note: Without explicit permission, neither the sa_role nor the sso_role can issue the set proxy login_name command. To use set proxy login_name, any user, including the system security officer, must have permission explicitly granted by the system security officer.

Before you can use the set proxy or set session authorization command, you must be granted set proxy privilege or set session authorization privilege in master.
You can switch your server user identity to any other server login and limit its use based on the target login roles by using:
```
grant set proxy to user_or_role_list
[restrict role role_list | all | system]
```
Executing set proxy or set session authorization with the original login_name reestablishes your previous identity.
You cannot execute set proxy or set session authorization from within a transaction.
The SAP ASE server permits only one level of login identity change. Therefore, after you use set proxy or set session authorization to change identity, you must return to your original identity before changing it again. For example, assume that your login name is “ralph”. To create a table as “mary”, create a view as “joe”, then return to your own login identity. Use the following statements:
```
set proxy "mary"
    create table mary_sales
     (stor_id  char (4), 
    ord_num   varchar (20),
    date      datetime)
grant select on mary_sales to public
set proxy "ralph"
set proxy "joe"
    create view joes_view (publisher, city, 
        state)
    as select stor_id, ord_num, date
    from mary_sales
set proxy "ralph"
```
If a user issues set proxy to assume the permissions, login name, and suid of another user, the SAP ASE server checks the proxy user’s access to database objects, rather than the original user’s access.

The SAP ASE server uses the name and password information of the user who logged in to check for automatic access to encryption keys using login credentials. The SAP ASE server does not have access to the proxy user’s password. Access to keys through the login password is on behalf of the user who logs in, not on behalf of the user assumed through an alias, set proxy, or setuser. Access to copies of encryption keys that were set up for login association, but which are still encrypted by the system encryption password or the master key, is treated similarily.