Microservice Serviceuser gets Access is denied

What product/components do you use and which version/fix level are you on?

Cumulocity 1013.0.167 on SaaS environment of eu-latest.
On Cumulocity 1011.0.12 on SaaS environment of alamos-dev it still works.

A microservice on basis of those two examples is used:

[GitHub - SoftwareAG/c8y-python-decoder-example-microservice: Python Microservice decoding Base64 Hex String](https://Python Decoder Example)

[GitHub - SoftwareAG/c8y_microservice-python: Cumulocity IoT - Microservice example developed using Python and Docker](https://Python Example)

Do you get any error messages? Please provide a full error message screenshot and log file.

Explanation

The example micro services request via the servicebootstraping an service user. This is as described in the documentation, the service user is received by the microservice.

The authorization is via ‘Basic base64({tenantid}/{user}:{password})’. However the service user has no privileges at all and gets an “Access is denied” for all API calls I tested. Within the manifest I do have the following required roles:

  • “ROLE_INVENTORY_READ”
  • “ROLE_INVENTORY_ADMIN”
  • “ROLE_MEASUREMENT_ADMIN”

I extracted the service user via:

GET “/application/applications/{ID}/bootstrapUser”

And tried the API calls via Postman, but do receive the same “Access is denied” message.
However I tested the same microservice on 10.11 where it perfectly worked as before and the service user works.

I checked under Administration that Basic Auth is still active:

Hi Murat,

I think you are mixing service user and bootstrap user.

GET “/application/applications/{ID}/bootstrapUser”

gets you the bootstrap user. You need to query

GET {{url}}/application/currentApplication/subscriptions

to get all subscriptions and their service users.

Best regards
Christian

Hi Christian,

that’s true, sorry for the mix up. However the service user does not get access from within the microservice environment within 10.13 but does within 10.11.

Hi Murat,
I just tested this on my end with version 1013.0.167 and cannot reproduce.

When calling the endpoint Christian mentioned with the bootstrap user how does the response look like?

GET {{url}}/application/currentApplication/subscriptions
Header: "Authorization": Base64(servicebootstrap_<<app-name>>:<<bootstrap-password>>)

So here is what I’m doing while getting an user within a microservice:

I query against C8Y_BASEURL + '/application/currentApplication/subscriptions with Authorization Header:
base64_credentials(C8Y_BOOTSTRAP_TENANT, C8Y_BOOTSTRAP_USER, C8Y_BOOTSTRAP_PASSWORD)

The output of this call:

2022-08-16 10:39:37,396 - Authentication - INFO - Logger for authentication was initialised
2022-08-16 10:39:37,396 - Authentication - INFO - Starting get_authorization
2022-08-16 10:39:37,396 - Authentication - INFO - Returning t15058219/servicebootstrap_decoder:SOMERANDOMPASSWORD
2022-08-16 10:39:37,456 - Authentication - INFO - [{'password': 'SOMERANDOMPASSWORD', 'name': 'service_decoder', 'tenant': 't15058219'}]
2022-08-16 10:39:37,456 - Authentication - INFO - Returning t15058219/service_decoder: SOMERANDOMPASSWORD
2022-08-16 10:39:37,456 - Authentication - INFO - Got auth: Basic SOMEBASE64ENCODEDTHING
2022-08-16 10:39:37,456 - Authentication - INFO - Getting tenantID
2022-08-16 10:39:37,457 - Authentication - INFO - TenantID is: t15058219
2022-08-16 10:39:37,457 - Authentication - INFO - Getting Base URL
2022-08-16 10:39:37,457 - Authentication - INFO - Base URL is: http://cumulocity:8111

The requests I’m applying against e.g. the identity API with:

t15058219/service_decoder: SOMERANDOMPASSWORD

does not work. Tested other API´s as well.
The log output for the request that is not working is:

2022-08-16 10:48:14,670 - Inventory API - INFO - Checking if external ID exists
2022-08-16 10:48:14,670 - Inventory API - INFO - Sending data to the following url: http://cumulocity:8111/identity/externalIds/c8y_Serial/67fzktfb75de6ud6n6edd6586f
2022-08-16 10:48:14,670 - Inventory API - INFO - The entry Authorization in the header is as following: Basic SOMEBASE64ENCODEDTHING
2022-08-16 10:48:14,670 - Inventory API - INFO - The entry Content-Type in the header is as following: application/json
2022-08-16 10:48:14,670 - Inventory API - INFO - The entry Accept in the header is as following: application/json
2022-08-16 10:48:14,673 - urllib3.connectionpool - DEBUG - Starting new HTTP connection (1): cumulocity:8111
2022-08-16 10:48:14,716 - urllib3.connectionpool - DEBUG - http://cumulocity:8111 "GET /identity/externalIds/c8y_Serial/67fzktfb75de6ud6n6edd6586f HTTP/1.1" 403 160
2022-08-16 10:48:14,717 - Inventory API - INFO - Response from request: {"error":"security/Forbidden","message":"Access is denied","info":"https://www.cumulocity.com/guides/reference-guide/#a-name-error-reporting-a-error-reporting"}
2022-08-16 10:48:14,717 - Inventory API - INFO - Response from request with code : 403
2022-08-16 10:48:14,717 - Inventory API - WARNING - Response from request: {"error":"security/Forbidden","message":"Access is denied","info":"https://www.cumulocity.com/guides/reference-guide/#a-name-error-reporting-a-error-reporting"}
2022-08-16 10:48:14,717 - Inventory API - WARNING - Got response with status_code: 403
2022-08-16 10:48:14,717 - Inventory API - ERROR - The following error occured: 
2022-08-16 10:48:14,718 - werkzeug - INFO - 10.244.146.0 - - [16/Aug/2022 10:48:14] "GET /test HTTP/1.1" 200 -

The SOMEBASE64ENCODEDTHING do match between the response of the application/currentApplication/subscriptions and the one used in the identity call.

EDIT: Just checked the received service_decoder with password via Postman and that works from external but not from within the container? Any header I’m missing?

Hi Murat,
so far it looks ok, no headers are missing.

I once had the issue that depending on the Base64-encoding it might be encoded with newline-characters which cause problems (aka “no wrap”).
Did you also double check and decode the encoded Base64 String to ensure it is in a good format?

Just checked, seems to be good. Base64 String is completely identical, tried both directions.

You requesting the identity API but miss adding the according role to the manifest (ROLE_IDENTITY_ADMIN or ROLE_IDENTITY_READ)
Adding it & re-deploying the microservice should fix the issue. Missing a required role in the manifest should also not work on any other version prior 1013 so this is not related to the version.

Does not work with any call at all. However it works with exactly the same zip, image, manifest on 10.11 but not on 10.13.

I do have the same issue again in on of my microservices and still have no clue where that behavior comes from.
The base64 Authorization header looks good, all API calls seems to be ok.

@Harald_Meyer and actually also @Stefan_Witschel had the right answers, thank you for that.

However to make a bit more clearer:

You need READ if you read from e.g. inventory. ADMIN does not overrule READ. So you need BOTH, READ and ADMIN.

@Murat_Bayram Yep, sorry for my “or”. In general all global roles are defined like the following rule:
Suffix READ → Read from the API
Suffix ADMIN → Create, Update, Delete (excl. Read).
Suffix CREATE → Create (excl. Update, Delete, Read)

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.