Scope "Admin" for OAuth2 grant type Client Credentials

jantonacci commented 3 years ago

Per https://github.com/vmware/idm/wiki/Integrating-Client-Credentials-app-with-OAuth2#app-registration-one-time-only in the "Create Client" image (see below), the required and only Scope available is "Admin". Per https://tools.ietf.org/html/rfc6749#page-23, the "The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions". Which I interpret as authorization server developers are required to implement this, yet the scope's significance is left TBD.

vIDM administrators are extremely reluctant to create this client type, yet it is a both recommended and necessary use case for API-to-API exchanges. Their assertion is the OAuth2 Scope "Admin" escalates the vIDM application privilege for the OAuth2 Client, granting application access with vIDM Administrator Role.

Does OAuth2 Scope "Admin" present a risk as described above? If yes, what is the prescribed risk mitigation and where is it documented? If no, where is the distinction between OAuth2 Scope and application roles documented?

Thank you.

pradyu commented 3 years ago

WS1 Access (vIDM) allows restricted roles to be created for admin based OAuth2 clients (although assigning of OAuth2 clients from the UI to roles is currently not supported, also this feature is currently only available on hosted environments)

1) Create a role from the Roles tab:

2) Grab the "id" of the ruleset the client needs to be associated by using the rulesets API:

GET https://{tenant.domain.com}/acs/rulesets
Authorization: HZN {HZN_cookie}
sample output: 
{
  "items": [
    {
      "id": "4059b5ba-6e77-4826-9b26-874ebe5daae4",
      "name": "Directory Admin",
      "disabled": false,
      "description": "Administrator with access to user, group and directory management",
      "rules": [
        {
          "disabled": false,
          "resources": [
            "vrn:ug:*",
            "vrn:dm:*",
            "vrn:tnts:*"
          ],
          "actions": [
            "*"
          ]
        }
      ],
      "builtIn": true,
      "_links": {
        "associations": {
          "href": "/acs/associations/rulesets/4059b5ba-6e77-4826-9b26-874ebe5daae4"
        },
        "self": {
          "href": "/acs/rulesets/4059b5ba-6e77-4826-9b26-874ebe5daae4"
        }
      }
    },
{
      "id": "1d0b09a1-8744-4f85-8c4f-ac104e586010",
      "name": "Super Admin",
      "disabled": false,
      "description": "Administrator with all access",
      "rules": [
        {
          "disabled": false,
          "resources": [
            "*"
          ],
          "actions": [
            "*"
          ]
        }
      ],
      "builtIn": true,
      "_links": {
        "associations": {
          "href": "/acs/associations/rulesets/1d0b09a1-8744-4f85-8c4f-ac104e586010"
        },
        "self": {
          "href": "/acs/rulesets/1d0b09a1-8744-4f85-8c4f-ac104e586010"
        }
      }
    }
  ],
  "totalCount": 2,
  "pageNumber": 1,
  "totalPages": 1,
  "pageSize": 20,
  "_links": {
    "next": {
      "href": "/acs/rulesets?startIndex=2&amp;pageSize=20"
    },
    "self": {
      "href": "/acs/rulesets?startIndex=1&amp;pageSize=20"
    }
  }
}

2) Grab the "id" of the OAuth2 client using the API

GET https://tenant.domain.com/acs/oauth2clients/{client_id}

Authorization: HZN {HZN_cookie}

sample request:
GET https://mydomain.vmwareidentity.com/acs/oauth2clients/test-client

sample output: 
{
  "id": "7965309e-d82d-3735-ad76-155b57f1e7ee",
  "clientId": "test-client",
  "secret": "",
  "scope": "admin",
  "authGrantTypes": "client_credentials",
  "accessTokenTTL": 180,
  "refreshTokenTTL": 129600,
  "refreshTokenIdleTTL": 5760,
  "displayUserGrant": false,
  "returnFailureResponse": false,
  "isOIDCClient": false,
  "enableAccessTokenFingerprint": false,
  "tokenType": "Bearer",
  "primarySecretAutoRetiresAt": 0,
  "additionalClaims": [],
  "_links": {
    "self": {
      "href": "/acs/oauth2clients/7965309e-d82d-3735-ad76-155b57f1e7ee"
    }
  },
  "rememberAs": "test-client"
}

3) Invoke the API to associate the client to the ruleset.

POST https://{tenant.domain.com}/acs/associations/rulesets/{ruleset_id}/client/{client_id}
Authorization: HZN {HZN_cookie}

sample request:
https://mydomain.vmwareidentity.com/acs/associations/rulesets/4059b5ba-6e77-4826-9b26-874ebe5daae4/client/7965309e-d82d-3735-ad76-155b57f1e7ee

sample output: 
HTTP 200 ok
{
    "_links": {
        "self": {
            "href": "/acs/associations/rulesets/4059b5ba-6e77-4826-9b26-874ebe5daae4/client/7965309e-d82d-3735-ad76-155b57f1e7ee"
        }
    }
}

Once these steps are performed, the client can only access the permissions granted to it.

Note: For authorization to the API's, Access token for an existing client with full access or the tenant administrator's cookie value needs to be provided.

jantonacci commented 3 years ago

Based on the above then...

Does a Client Credentials grant w/ OAuth2 Scope "Admin" present a risk? Yes.
What is the prescribed risk mitigation and where is it documented? Custom API calls are required to properly provision a Client Credentials grant w/o the OAuth2 Scope "Admin" per the above detailed description.

Thank you for the detailed explanation.

vmware / idm

Scope "Admin" for OAuth2 grant type Client Credentials #15