Cancel
Showing results for 
Search instead for 
Did you mean: 

Azure Tenant - iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTechUser

Siemens Creator Siemens Creator
Siemens Creator

For my Azure Tenant I was earlier getting the scope as mdsp:core:Admin3rdPartyTechUser and now suddenly for same Tenant it has changed to iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTechUser. Due to this my Write APIs are not working anymore as I get Insufficient scope for this resource error message.

Does anyone have an idea why it happened?

 

Note: This is Azure Tenant and it still has old Authentication process of client-Id and client-secret which are received from Mindsphere support team and not from Apps.

 

Thanks in Advance...

7 REPLIES 7

Re: Azure Tenant - iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTech

Legend
Legend
So the change is that you are now receiving a scope with two values, the previous one plus a new one? Sorry if I'm misunderstanding

Re: Azure Tenant - iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTech

Siemens Creator Siemens Creator
Siemens Creator

Thank 

No, I am receiving the scope as one value :

"scope": "iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTechUser",

The name is little crazy with space in it.

 

 

 

 

Re: Azure Tenant - iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTech

Legend
Legend

No sorry, those are two values in a single, space-delimited string. Afaik that is spec-compliant, and the way multiple scopes should be sent back:

 


In my own API calls I see multiple scopes involved, space-delimited.

You should make your code parse that space-delimited list and then check for the appropriate value you are interested in. I would expect that extra scopes can be added anytime (as you have already experienced), as long as they don't interfere with the existing ones.

Re: Azure Tenant - iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTech

Siemens Creator Siemens Creator
Siemens Creator

yes you are correct , Just saw in jwt.io the Decoded part  :

"scope": [
"iam-action.client_credentials.subtenant-impersonation",
"mdsp:core:Admin3rdPartyTechUser"
],

 

But how can I separate it out in token I mean I get the Authorization Token as:

{
"access_token": "eyJhbGciOi....",
"token_type": "bearer",
"expires_in": 1799,
"scope": "iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTechUser",
"jti": "7a66daa47cc24e5797f4bba5160b77cf"
}

 

I can just use the access_token I get in my code further for Mindsphere Timeseries Write API - But bcoz the scope is limted it gives me follwing error :

{

"status": 401,
"error": "Unauthorized",

"exception": "org.springframework.security.access.AccessDeniedException",

"message": "Insufficient scope for this resource",

}

 

 

 

 

 

 

Re: Azure Tenant - iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTech

Siemens Creator Siemens Creator
Siemens Creator

Earlier when I was getting the scope as only : 

scope": [
"mdsp:core:Admin3rdPartyTechUser"
],

It was working fine, I was able to Write with the same code.

Re: Azure Tenant - iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTech

Siemens Creator Siemens Creator
Siemens Creator

Now by GTAC support, they gave me another user where I can see in Token my scope as :

scope": [
"mdsp:core:Admin3rdPartyTechUser"
],

But it's still now working for Write API - giving me the same error :

"status": 401,
"message": "Insufficient scope for this resource",

 

This means it not only about scope the Token shows,  but something deeper - maybe some regression defect.

 

 

Re: Azure Tenant - iam-action.client_credentials.subtenant-impersonation mdsp:core:Admin3rdPartyTech

Siemens Creator Siemens Creator
Siemens Creator

The problem is solved now...

 

After GTAC did some changes for Tenant and then I got:

 {
"access_token": "eyJhbGciOi....",
"token_type": "bearer",
"expires_in": 1799,
"scope": "mdsp:core:Admin3rdPartyTechUser",
"jti": "7a66daa47cc24e5797f4bba5160b77cf"
}

But still this was not workig even when access_token and scope was correct for writing.

 

GTAC then gave my client_id the access and it starts working normally.

 

This means that even if you see that token has access and here is proper scope still you may not be able to write -  internally there may be no access granted - Don't know how it is internally but looks like this.