User Permissions
Organization-wide Default User Permissions
This Public Experimental API supplies an organization-wide default user permission and allows users to log into the PCE and view resources. These resources must not be explicitly assigned to any RBAC roles or scopes.
About Default User Permissions
If you use an external identity provider for user management, you might want to block some of those users from the PCE without removing them from your identity provider. Deleting the organization-wide read-only permission allows you to achieve this.
When the read-only user permission is disabled for your organization, users not explicitly assigned this permission cannot log into the PCE and access Illumio resources. If users, without permission, attempt to log into the PCE, their external identity provider authenticates them, but the PCE immediately logs them out.
To disable organization-wide read-only permissions:
Get a collection of all authorization security principals in your organization, and search the response for the one named
null. Once you find this authorization security principal, note its full HREF.Get the HREF of the permissions object associated with the
nullauthorization security principal. Keep a record of the JSON object for this permission if you want to re-enable the permission at a later date.Delete the permission associated with the
nullauthorization security principal.
Get a Collection of Authorization Security Principals
The first step in disabling the organization-wide read-only permission is to get a collection of all authorization security principals in your organization.
Get Permission for Null Auth Security Principal
To get the permission object associated with the null authorization security principal, call the GET Permissions API with the query parameter value set to the HREF for the null authorization security principal, similar to the curl command:
curl -i -X GET -H "Accept: application/json" -u $KEY:$TOKEN https://pce.mycompany.com:8443/api/v2/orgs/7/permissions?auth_security_principal=/orgs/7/auth_security_principals/a23ea011-4191-49e6-a22a-d3dba4fb8058
Response
The response returns the HREF of the permission associated with the organization-wide read-only permission.
{
"href": "/orgs/7/permissions/14c92849-e88e-4930-8804-3245565619e5",
"role": {
"href": "/orgs/7/roles/read_only"
},
"scope": [],
"auth_security_principal": {
"href": "/orgs/7/auth_security_principals/a23ea011-4191-49e6-a22a-d3dba4fb8058"
}Delete Null Authorization Security Principal Permission
Keep a record of the permission object returned in case you want to re-enable the permission in the future.
Delete the read-only permission HREF to disable it.
Curl Command to Delete Null Authorization Security Principal Permission
curl -i -X DELETE -H "Accept: application/json" -u $KEY:$TOKEN https://pce.mycompany.com:8443/api/v2/orgs/7/permissions?auth_security_principal=/orgs/7/auth_security_principals//orgs/7/permissions/14c92849-e88e-4930-8804-3245565619e5
Response
An HTTP 200 response is returned on successfully deleting the organization-wide read-only permission.
Re-Enable Organization Read-Only Permission
If the organization-wide read-only permission was disabled, you can re-enable it by recreating the permission object. This object must be constructed exactly as the object returned to you when you got the permission. The request body below illustrates the JSON structure of this permission object.
Reference and Examples for Default User Permissions
Curl Command Get Auth Security Principals Collection
curl -i -X GET https://pce.mycompany.com:8443/api/v2/orgs/7/auth_security_principals -H "Accept: application/json" -u $KEY:$TOKEN
Example Response Body
The null authorization security principal in the following example is highlighted in blue:
[
.......................................................
{
"href": "/orgs/7/auth_security_principals/a23ea011-4191-49e6-a22a-d3dba4fb8058",
"name": null,
"display_name": null,
"type": "group"
},
.......................................................
]URI to Enable the Organization-Wide Read-Only Permission
POST [api_version][permission_href]
Request Body
{
"role": {
"href": "/orgs/7/roles/read_only"
},
"auth_security_principal": {
"href": "/orgs/7/auth_security_principals/a23ea011-4191-49e6-a22a-d3dba4fb8058"
},
"scope": []
}Curl Command to Enable Organization Read-Only Permission
curl -i -X POST https://pce.mycompany.com:8443/api/v2/orgs/7/permissions -H "Content-Type: application/json" -u $KEY:$TOKEN -d '{"role": {"href": "/orgs/7/roles/read_only"}, "auth_security_principal":{"href":"/orgs/auth_security_principals/a23ea011-4191-49e6-a22a-d3dba4fb8058"}, "scope": []}'Response
An HTTP 201 response is returned on successfully recreating the organization-wide read-only permission.
App Owner RBAC Role
The App Owner RBAC (Role-Based Access Control) role hides information in the PCE that is not relevant to the user with that role. At the same time, the app owners can write effective rules to secure their apps and restrict visibility within the PCE to the permitted scopes for users.
RBAC previously restricted only the write permission for users, while the read permission was unrestricted, and every user had visibility into PCE. The App Owner RBAC role also restricts the read permission to correspond to the user roles. This accelerates enterprise-wide expansion so that customers who acquired Illumio for a single application can expand faster.
The introduction of the App Owner role solves these problems because it does the following:
Accelerates micro-segmentation deployment by allowing for scaling after an organization implements micro-segmentation with smaller applications.
Assures compliance with good security practices so that users cannot view the sensitive information they are not allowed to see.
It eliminates the complexity of building a custom portal. App Owners can use Illumio REST APIs instead of the custom UIs created by customers.
App Owners are responsible for managing vulnerabilities in their applications for which the PCE owners can assign scoped roles.
App Owner Roles
The roles of Ruleset Managers, Ruleset Provisioners, and Workload Managers are assigned to users and user groups. These roles can be expanded to give users additional read/write permissions. All permissions are additive.
Ruleset Manager with Scoped Reads
This RBAC role has the write permission that allows its owner to change the policy. Users with this role can see in the PCE only the content related to their location instead of having full read-only access to the entire PCE content as before.
The role now also supports scoped reads.
Ruleset Provisioner with Scoped Reads
This RBAC role can provision policy changes to workloads. Users with this role can see only the content related to their location in the PCE instead of having full read-only access to the entire PCE content.
The role now also supports scoped reads.
Ruleset Viewer
This RBAC role has access to the PCE to manage one or more applications. Users with this role can view their application and its dependencies, but they cannot view information about other applications.
Workload Manager with Scoped Reads
This RBAC role provides a control for managing workloads. Users with this role can see only the content related to their scope in the PCE instead of having full read-only access to the entire PCE content.
The role now also supports scoped reads.