The assumeRole action allows a user to temporarily adopt a specific administrative role within the CAS session. This is a powerful feature for administrators who need to perform tasks requiring elevated permissions without permanently changing their user rights. By assuming a role like 'SUPERUSER', 'DATA', or 'ACTION', the user gains unrestricted access to specific areas of the CAS server for the duration of the role assumption. This is crucial for managing access controls, data, or actions securely and efficiently.
| Parameter | Description |
|---|---|
| adminRole | Specifies the administrative role to assume. 'ACTION' provides unrestricted access to actions and action sets. 'DATA' provides unrestricted access to caslibs, tables, and columns. 'SUPERUSER' combines the privileges of both ACTION and DATA roles, and adds the ability to manage roles and paths. |
The `assumeRole` action does not directly interact with or create data tables. It is an administrative action used to manage session permissions.
| 1 | /* No |
| 2 | data creation code is necessary for this action. */ |
This example demonstrates how to assume the 'SUPERUSER' role. This grants the highest level of permissions for the current session.
| 1 | |
| 2 | PROC CAS; |
| 3 | |
| 4 | ACCESSCONTROL.assumeRole / adminRole='SUPERUSER'; |
| 5 | |
| 6 | RUN; |
| 7 |
This example shows how to first assume the 'DATA' administrator role to perform data-related administrative tasks, and then how to drop that role to revert to the original permissions.
| 1 | PROC CAS; |
| 2 | /* Assume the DATA role to manage data access controls */ |
| 3 | ACCESSCONTROL.assumeRole / adminRole='DATA'; |
| 4 | PRINT 'Current session has assumed the DATA role.'; |
| 5 | |
| 6 | /* ... perform administrative tasks on caslibs or tables ... */ |
| 7 | |
| 8 | /* Drop the assumed role to return to normal permissions */ |
| 9 | ACCESSCONTROL.dropRole / adminRole='DATA'; |
| 10 | PRINT 'The DATA role has been dropped.'; |
| 11 | RUN; |
This example illustrates how permissions change by first checking authorization for a specific action, then assuming the 'ACTION' role, and finally re-checking the authorization. This is useful for verifying the effect of `assumeRole`.
| 1 | PROC CAS; |
| 2 | /* 1. Check if the user is authorized for a specific action before assuming a role */ |
| 3 | ACCESSCONTROL.isAuthorizedActions / actions={{name='serverstatus', actionSet='builtins'}}; |
| 4 | |
| 5 | /* 2. Assume the ACTION role */ |
| 6 | ACCESSCONTROL.assumeRole / adminRole='ACTION'; |
| 7 | |
| 8 | /* 3. Check authorization again to see the change in permissions */ |
| 9 | ACCESSCONTROL.isAuthorizedActions / actions={{name='serverstatus', actionSet='builtins'}}; |
| 10 | |
| 11 | /* 4. Drop the role to clean up the session state */ |
| 12 | ACCESSCONTROL.dropRole / adminRole='ACTION'; |
| 13 | RUN; |
A Data Steward, who normally has read-only access to production data, needs to perform an audit on a sensitive HR table containing employee salaries. To do this, they must tempo...
A security team wants to ensure that a user in a 'LimitedAnalysts' group cannot escalate their privileges to 'SUPERUSER'. The test must verify that the `assumeRole` action is pr...
An MLOps pipeline, running under a service account, needs to deploy a new version of a custom scoring action set ('customScoring'). The service account has minimal permissions b...