Issue with datamask custom role permissions

Hello,

I'm trying to create an Org level data mask in Apigee Edge through pipelines so I followed this documentation and created a custom role with these permissions:

 

 

 

{
    "resourcePermission": [
        {
            "organization": "[omitted]",
            "path": "/maskconfigs",
            "permissions": [
                "put",
                "get"
            ]
        },
        {
            "organization": "[omitted]",
            "path": "/maskconfigs/*",
            "permissions": [
                "put",
                "get",
                "delete"
            ]
        },
        {
            "organization": "[omitted]",
            "path": "/applications/*/maskconfigs",
            "permissions": [
                "put",
                "get"
            ]
        },
        {
            "organization": "[omitted]",
            "path": "/applications/*/maskconfigs/*",
            "permissions": [
                "put",
                "get",
                "delete"
            ]
        }
    ]
}

 

 

 

(where [omitted] is the name of our Apigee organization) and then I added our Apigee machine user to that custom role above.

But then when I go to create a data mask using that same machine user I get a 403 Forbidden error back; Our machine user has other custom roles and is able to create proxies or make a variety of other calls without issue.

I am able to create an org level data mask in Apigee through postman using my own user (as an organization administrator). But when I try to make the same call with the above permissions on a custom role I get that 403 back (tested by removing my own user from all other roles aside from that new custom role noted above and making the same postman call which had worked for me previously to create an org data mask before when I had the org admin role on my user).

Any suggestions would be appreciated - looks like someone asked roughly the same question awhile back but there were no responses to that.

Thanks!

Jared

Solved Solved
0 3 113
1 ACCEPTED SOLUTION

hmm it looks like you're doing the right thing. 

I don't know why it's failing - that looks like the right path + permission combinations to use. 

You can check the permissions on a role like this: 

GET :mgmtserver/v1/o/:orgname/userroles/:role/permissions
Accept: text/xml
Authorization: :apigee-auth

Does that give you back what you think you should get? 

If not, then you need to check how you've set up the permissions on the role.  If it DOES give you back what you think you should get, then you need to verify that the user is ACTUALLY in the given role.  

And if that still looks good, then ... I guess contact Apigee support.

(Not that it helps you, but This is easier in Apigee X)

View solution in original post

3 REPLIES 3

hmm it looks like you're doing the right thing. 

I don't know why it's failing - that looks like the right path + permission combinations to use. 

You can check the permissions on a role like this: 

GET :mgmtserver/v1/o/:orgname/userroles/:role/permissions
Accept: text/xml
Authorization: :apigee-auth

Does that give you back what you think you should get? 

If not, then you need to check how you've set up the permissions on the role.  If it DOES give you back what you think you should get, then you need to verify that the user is ACTUALLY in the given role.  

And if that still looks good, then ... I guess contact Apigee support.

(Not that it helps you, but This is easier in Apigee X)

Hi, really appreciate you taking a look at this. You were right to have me re-check the user was linked up. I really thought I had tripled checked that - but there was something a little tricky going on in our CICD where we pulled one users credentials and then overwrote the values with a 2nd users credentials later on. Anyways, working now, thanks again!

ahhhh, splendid.  
Sometimes one extra set of eyes (even remote, virtual eyes) is all the help you need.  Glad you got it sorted.