Authentication and authorization

[pacosta]

The app that I am developing has an entry in the "Settings" section. I am binding to a Unix socket as recommended in the "How-to: Integrate into the ctrlX CORE system" document. As far as I can tell the proxy is sending HTTP (not HTTPS) requests through the Unix socket. I am correct in assuming that the proxy will only let properly authenticated requests be forwarded to my app, and handle user log-in if they are not? 

[CodeShepherd]

When your app is set "behind" the reverse proxy all requests have to be sent via https to the ctrlX CORE and will be checked by the authentication server. After this is done the requester will get a token including all rights for the system. With this token the requester can now send htpps requests without authenticate again. Internally this messages will now be handled in http but your app will have to check the authorization for its own functions. The proxy only knows the right but does not know what to do with it.

[jochen-scheib]

In addition to CodeShepherds answer:

The reverse proxy will validate the following properties of the token for all incoming https request:

• Is the signature of the token valid
• Is the token expired
• Is the session still on the whitelist (e.g. when you delete a session using the user & permissions dialog)

It will not validate any scopes, that has to be done in your application.

The reverse proxy will do this validation for all paths that are listed in the restricted array of the package-manifest, including all subpath.

[pacosta]

Two follow-up questions:

1) If I make the proxyMapping URL of my app as restricted, I get an HTTP 401 error every time I want to access it from the ctrlX CORE sidebar. I don't see GET request for that page having a bearer token in the headers. Is this expected behavior?

2) I defined two scopes in the package manifest, and from the code snippet in section 5.1 of the  "How-to: Integrate into the ctrlX CORE system", it seems that the scope are part of the request, but again, I don't see them in the request object... I have added the user to these scopes. How is this supposed to work?

The package manifest is attached (renamed to .csv so that I could upload it)

Thank you!

[CodeShepherd]

1. We found a misbehaviour of the system for that case and are analyzing it.
2. Please try the setting:
   

   "link": "/my-app?access_token=${bearertoken}"​

[CodeShepherd]

Actual status is that during check was found that the system is running correct.

The setting that has to be used is:

"link": "/my-app?token=${bearertoken}"​

We will extend the examples in the SDK and the corresponding documentation.

[pacosta]

I am still not getting anywhere with this 😕

a. How am I supposed to access the API from within the snap (i.e. how do I get the appropriate hostname?) I tried via the reverse proxy socket (did not work), with "localhost" as the hostname of an HTTP request (did not work either), or shelling out with the command `ip route get to 1` (did not have enough permissions even though I listed all network-* plugs for my app).

b. I can get the authentication token with the GET query parameter access_token=${bearertoken}. But then... what? Assuming I get the right hostname for an HTTP request (see point a) I see that there is an API /identity-manager/api/v1/auth/token/validity... but I don't see where I am supposed to pass the token that I received to validate it.

c. I still can't find where/how the scopes are passed when there is a request to the path I list in the proxyMapping.url property, in the package manifest. There are no scope(s) in the header, or in the body that I can see.

Is there any example of an app that actually uses the reverse proxy and serves up an HTML page? I cannot find anything like this in the SDK, and it would be very helpful to shortcircuit some/all of my questions.

Thank you for any help you can provide,

Pablo

[JohannesA · Accepted solution]

Hi Pablo,

let me try to answer a few of your questions.

a) Your assumption is correct, you can access the API via https://localhost/api/... (please note that https, not http is important). This should work when you include the bearer token in your request header or query parameter. This most likely the [network-bind] interface in your snapcraft.yaml

b) The token validity in terms of signature and expiration is checked for you via the reverse proxy, there is nothing you have to do manually. 

c) The scopes are part of the bearer token. You have to parse the bearer token in your application and check whether the scope that your application expects is present. You can use https://jwt.io/ to decode a sample bearer token. For example your bearer token might look like this (encoded):

{
"exp": 1619214790,
"iat": 1619185990,
"id": "1000",
"name": "boschrexroth",
"nonce": "5844eb6f-46b1-48ff-9508-850bf65bd209",
"plchandle": 0,
"remoteauth": "",
"scope": [
"rexroth-device.all.rwx"
]
} 

We are currently working on an example which will be part in the future SDK, but it is not finished yet.

Regards 

Johannes

[pacosta]

Thanks! These answers helped me get the scopes and authorization done.

FYI, for API interactions I had to configure the HTTPS call to turn off security checks, which is the same thing I need to do when I access the ctrlX CORE through the browser, since the certificate appears to be invalid.

[CodeShepherd]

As a short addition:

The certificate is not invalid but is self signed by Boschrexroth, because we cannot make sure that each IP address that can be assigned to any ctrlX CORE is a save device and be registered in the internet. That's why you will get this waring when connecting with a browser.

[pacosta]

Indeed, thank you for the correction/clarification.