Important
The Forced Permission functionality has been deprecated and replaced with the Alias feature.
Legacy users of forced permissions can still continue to use the feature. However, new users, or existing users who never configured forced permission
The forcedPermission attribute is used to set user roles in NetCloud Manager. The forcedPermission attribute's value is set in JSON format.
When the forcedPermission attribute is set for a user, it is evaluated each time the user logs in. This allows administrators to set or change a user's NetCloud Manager role or account in the IdP app, if necessary. The changed role or account is applied the next time the user logs in with SSO.
Set the forcedPermission attribute by adding a name for the attribute in the Name field of the Attribute Statements section in the Okta app.
Add the JSON that describes the role and the account containing the role. See the table below for examples.
The JSON used for the forcedPermission value is a JSON array that can contain multiple JSON objects. Each JSON object contains a role attribute and account attribute.
The role attribute contains a string value of the role name.
The account attribute contains an array of strings of the account name where the role is assigned. This allows subaccounts to be identified so roles can be assigned in them. In the following snippet, a role is applied to Subaccount1a, nested under Subaccount1.
"account":["Subaccount1","Subaccount1a"]
If an empty array [] is used for the account attribute value, then the root account is used.
"account":[]
The following table contains examples of the JSON required when setting the forcedPermission attribute. This shows how to set various roles in different accounts.
Use Case | JSON Value |
|---|---|
Puts a user in the Root Account with an Administrator role. | [{"role":"Cradlepoint_Admin","account":[]}] |
Puts a user in Subaccount1 with an Administrator role. | [{"role":"Cradlepoint_Admin","account":["Subaccount1"]}] |
Puts a user in Subaccount1 with a Diagnostic User role | [{"role":"Cradlepoint_Diagnostic","account":["Subaccount1"]}] |
Puts a user in Subaccount1a (the child of Subaccount1) with an Administrator role. | [{"role":"Cradlepoint_Admin","account":["Subaccount1","Subaccount1a"]}]NoteThe values in the "account" array used in examples like this, ["Subaccount1","Subaccount1a"], represent the path to the account. This does not mean that the permission will be applied to multiple accounts; it means that Subaccount1a is nested beneath Subaccount1. |
Puts a user in Subaccount1a (the child of Subaccount1) with a Full Access User system role. | [{"role":"Cradlepoint_FullAccess","account":["Subaccount1","Subaccount1a"]}] |
Puts a user in Subaccount2b (the child of Subaccount2) with a Read-Only system role. | [{"role":"Cradlepoint_ReadOnly","account":["Subaccount2","Subaccount2b"]}] |
Puts a user in the Root Account with an Installer custom role. | [{"role":"Custom_Installer","account":[]}] |
The forcedPermission attribute can be set in a SAML assertion. The first examples shows how to correctly set the forcedPermission attribute.
<Attribute Name="forcedPermission">
<AttributeValue>[{"role":"Cradlepoint_Admin","account":[]}]</AttributeValue>
</Attribute>The following is an incorrect example of setting the forcedPermission attribute in a SAML assertion. This example specifies the format of the attribute and will not work.
<Attribute Name="forcedPermission">
<AttributeValue a:type="tn:json" xmlns:tn="http://www.w3.org/2001/XMLSchema" xmlns:a="http://www.w3.org/2001/XMLSchema-instance">[{"role":"Cradlepoint_Admin","account":[]}]</AttributeValue>
</Attribute>