Skip to Content (Press Enter)
UserImage.jpg
Robert Honiball
397Views
5Comments
Expose and Consume REST API - Security
Question
REST
Reactive
API
Security
Service
Application Type
Reactive, Service
Service Studio Version
11.11.2 (Build 42827)

Hi, I've tried researching this, but I keep getting half answers and constantly end up hitting walls.

I am trying to expose an API for an external Company to use, but before we give them the documentation, I'd like to test it myself (in Outsystems). Exposing and Consuming the APIs I can do with little effort, but now I would like to add some security to it.

Ideally, I would like to use a Service account, but I'm unclear as to how to use the Token I received (in LifeTime) with Basic Authentication - as the Token is 200+ characters long and Basic's Username/Password are both capped at 128.

Does that mean that I need to create a User Account in LifeTime for every company that potentially uses the API instead of Service Accounts

How would I need to adjust the module to Log In using the LifeTime account rather than using the Built-In Users table - that we are using for our End-Users

Thanks
Robert

Edit: What I'm trying to achieve is the following:
We have an external company that will provide us with users and data for our platform, and I need to create the user and link its corresponding data back to it.

The problem I am having is that I need to create a User in the Users Table, using the built in function - which requires the User Manager Role, meaning I need to create a User before a User exists

So I came to the conclusion that I need to log in as an existing user, apply the role to that user, and create the client without issue. But I cannot use our existing End-User credentials, as they will likely need to be directed to whichever Company the clients are coming from - hence the Service Account seems to be the most likely solution

But I am given a Token that I have no idea how to Expose, and applying it in the Consuming step yields a "header not well formed" message - and the token is too long for the Basic Username and Password fields.

If I am doing this wrong from the start, I am open to any other solutions that will help accomplish my task

0
0
08 Jun 2021
Copy Link
UserImage.jpg
Robert Honiball

Hi Daniel, I have read these before.

Regarding the first link you sent - I have followed the instructions, created the Service Account, saved the token but I get stuck as to how to apply the Token I received during the Expose stage - does it fall under Basic or Custom - how would I log in using the token to get the User ID for the Service Account. During the Consuming of the API, following the Authorization step, I get an error message saying "Header not well formed" or something to that effect - which leads me to assume that I Exposed it wrong.

Regarding the Second link, a colleague of mine have followed the steps, and without me needing to supply anything, it approved the connection automatically, which seems to be ineffective as it always approved the connection

And the last Link -the forge post - It appears to be outdated and cannot open - I get the following error

0
0
08 Jun 2021
Copy Link
2021-04-01 07-44-07
João Coelho

Is there a way to use a service account token to call lifetime exposed services in Outsystems 10?

0
0
25 Jan 2022
Copy Link
2020-09-01 10-42-42
Stefano Valente

"How would I need to adjust the module to Log In using the LifeTime account rather than using the Built-In Users table - that we are using for our End-Users"


I have read your post for about 4 times and i still don't understand what you are trying to do. so i am probably going to say some stupid things. Please help me by answering them :)


- Why would you want your external parties to have a lifetime user account or service account? they will get too much rights in any case. With a lifetime user, for instance, they would be able to log into lifetime and service center.

- for this purpose, if you want to use the OS users architecture, i would recommend to create a Userprovidermodule and get all useraccounts to be marked as external user (this is cheaper). You can create maintenance-userscreens for this userprovider and make them only accessable for your service center user.


Ofcourse another option would be to introduce OAuth. 

0
0
25 Jan 2022
Copy Link
2021-10-09 07-57-44
Stefan Weber
 
MVP

I have to agree with @Stefano Valente. The intent is not really clear what you want to achieve. Let me try to figure that out.

You have provisioned user accounts in OutSystems for your API consumers.

You want that when someone (having a user account from you) connects to your API, that the processing of the request is done under that user rights.

You cannot use the default basic authentication (username and password) for some reasons (just my opinion: Basic auth shouldnt be used anyhow).

Stefano already mentioned OAUTH as an alternative. Let me try explain a simpler approach (ok it is just minimal simpler) using JSON Web Token.

  • Your API consumer creates a signed and encoded JSON Web Token. That webtoken has a sub claim with the OutSystems username. See jwt.io for available libraries on creating JSON Web Tokens.
  • Your API consumer sends that encoded token via the Authorization Header (Bearer: <Token>)
  • You set your Exposed API to custom authentication (see above links from @Daniël Kuhlmann)
  • In the OnAuthentication flow you get the signed and encoded token. You validate the token (public or symmetric key necessary) and other stuff like issuer, audience and expiraton date. The JWT Forge component does basically all that for you.
  • After successful validation you take the sub claim from the token, query your users table for the username and upon retrieval perform a User_Login for that account.



1
0
25 Jan 2022
Copy Link
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.