GetEntryEspaceID in ServiceAction

Hi,


I'm using the GetEntryEspaceID() function to manage permission for a server action. 

However, now I found that this doesn't work in Service Actions. GetEntryEspaceID returns the module of the service action, not the requestors module. (probably as they run in their own context). Is there another way to get the Espaceid of the service actions requestor? I tried GetOwnerEspaceID  but its giving the same id (Service Action module).

Why not you sent the EspaceId to the Server action you are calling as an input parameter.
This was you can receive the Espaceid of the Source action & you can use it further.

assif_tiger wrote:

Why not you sent the EspaceId to the Server action you are calling as an input parameter.
This was you can receive the Espaceid of the Source action & you can use it further.

Hi Assif, I don't want the consumer of the service action to provide the espaceid as an input because they can tamper around with what they provide. Even if you set the input parameter as "Espace identifier" you can fill any integer.

Hi Christoph,

I ran into the same problem last year, and could not find a solution for that.

Regards,

Daniel

Christoph Newe wrote:

assif_tiger wrote:

Why not you sent the EspaceId to the Server action you are calling as an input parameter.
This was you can receive the Espaceid of the Source action & you can use it further.

Hi Assif, I don't want the consumer of the service action to provide the espaceid as an input because they can tamper around with what they provide. Even if you set the input parameter as "Espace identifier" you can fill any integer.

Agree,but what if you pass GetEntryEspaceID directly in Inpit  & validate on receiver action whether its a valid eSpaceId or not by using eSpace entity.



@Assif, the problem is that espaceid is a running number so consumer can use getespaceid to find out their own and then just increment to pretend call is from another espace.

It's really a pitty, I wanted to use this as an API Key replacement which seems pretty save because the caller does not even provide the espaceid, we examine it on our side. 

Hi Christoph,

We were trying to implement the same functionality and decided to stick to server actions and not service actions.

Then you can implement what you want (and it also faster!)

Regards,

Daniel

If you don't ask me asking, I'm just curious; Why are you afraid that someone will add an tampered espace number to your action? I know that it is possible that this is happening but it's not that this is done by an end-user. It's done by a programmer and that is manageable, at least in my experience it is.  Please mind that I have a very small number of developers force so perhaps my world it totally different than yours.

Hi Vincent,

I can see why there is a security risk. Picture this. A big financial company, with multiple development teams with different external hires on teams over time. A certain API credential to access financial information in  a certain domain should only accessible by Team X owned applications . If a team member from team Y (that owns other applications) maliciously wants to use the API, you want to avoid him being able to get API credentials.

The above scenario is based on my own project experience.

Regards,

Daniel

Hi Daniël Kuhlmann,

Thanks for sharing the use-case & agree with Christoph Newe for the concern he raised.

If there's an idea posted already kindly let us know the link in order to +vote.

- Assif


I think Daniel provided a good use case. 

If you have an application for lets say "affiliate a" and another for "affiliate b" and those are completely seperate from customer, developer perspective. You might want to provide functionality (Actions,Blocks) to a but not to b.

Or you might want to do an assessment before you grant permissions for a specific action.


Maybe helpful for someone else with a similar problem: You can grant a developer access on application level. So all actions within this application would not be accessible (they don't see them in the "manage dependencies" window.

Daniël Kuhlmann wrote:

If a team member from team Y (that owns other applications) maliciously wants to use the API, you want to avoid him being able to get API credentials.

I can see your point but if you want to fix this that you need to take bigger steps then just verifying the espace id. This goes down to credibility of your own personnel/partners. If there are trust issues here then this is not something that you need to fix technically. 

And if you want to solve it technically then you will need to even architect the application around this issue and implement a strong authentication method. I personally would then not implement espace id verification or an API Key but I would try to implement oAuth2 to protect my endpoints. This would give me a much more robust framework where the access management is not handled in an OutSystems application but in a 3rth party tool (like Azure AD) with it's own separate access. But that's a whole other topic (and nice whitepaper material, hummm :))

Vincent Koning wrote:

Daniël Kuhlmann wrote:

If a team member from team Y (that owns other applications) maliciously wants to use the API, you want to avoid him being able to get API credentials.

I can see your point but if you want to fix this that you need to take bigger steps then just verifying the espace id. This goes down to credibility of your own personnel/partners. If there are trust issues here then this is not something that you need to fix technically. 

And if you want to solve it technically then you will need to even architect the application around this issue and implement a strong authentication method. I personally would then not implement espace id verification or an API Key but I would try to implement oAuth2 to protect my endpoints. This would give me a much more robust framework where the access management is not handled in an OutSystems application but in a 3rth party tool (like Azure AD) with it's own separate access. But that's a whole other topic (and nice whitepaper material, hummm :))

It is not about trust, it is about safety measures that somebody does not make misuse of your trust. For financial companies, or in case of confidential data this is relevant. 

Regarding OAuth you have a point but OAuth is not always possible depending on with which legacy systems you need to integrate.

Daniël Kuhlmann wrote:

It is not about trust, it is about safety measures that somebody does not make misuse of your trust. For financial companies, or in case of confidential data this is relevant. 

Regarding OAuth you have a point but OAuth is not always possible depending on with which legacy systems you need to integrate.

Security is all about trust, or better, the lack of ;).

But we are not talking about legacy systems, we are talking about integrating OutSystems applications with each other and then oAuth2 is actually a bit to much. I don't have enough experience with this due to my small environment but I think this issue should be solvable with the building blocks native present and without any checks whatsoever.


Hi Vincent,

Regarding the legacy systems comment I made:

We had to store credentials for legacy systems we integrate within a secure way (Service Center Site properties, was not an acceptable solution). The legacy systems could not be authenticated through OAuth.

For that like Christoph, we create an OutSystems Service that securely could store these credentials.

So yes, consuming the service from within OutSystems is indeed OS talking to OS, but that was not the point.

The point is that those credentials should not be retrievable, by teams that should not are authorized to use them.

Regards,

Daniel