How to manage User Role in screen if I use external user table by REST API ?

Hi everyone, I have a question about user management.

I know I can use Outsystems User table to manage the User Role. My question is if I use an External User table by API, how can I manage the role in the screen.

Since there are screens only allow Management level person to see the screen content.

Please advice, thanks

Hello Jack, 

If you don't login the user in OutSystems, you can't, I'm afraid... Not without adding extra logic that probably will not be very Safe (requiring checking authorization on preparation, keeping tokens, etc). 

The recommended way to authenticate a user on an external system is:

1. Check if the user exists in the User entity. If not, created it. 

2. With the OutSystems user Identifier, found or created, grant the required roles. 

3. Silently login in OutSystems using the System Login action (requires only user Id). 

This way you will have all the benefits of the platform regarding authorization, like the page role access control. 

There is a whole path on the learn section on authentication. 

https://www.outsystems.com/learn/courses/120/authentication/

Hope this can help. 

Cheers

Hi Jack,

I totally agree with the steps suggested by Eduardo. Additionally, You may automate step 2 based on API response. If you've trusted API and can get the security group/role in the response, this can be programmed to grant the role in OutSystems.

Regards

Swatantra

Just to add to the above a case study, we have a customer portal running in an on-premise DMZ, with a back-end that's not reachable from the internet, also running on-premise. Between the DMZ server and our back-end server there's a REST API, that processes user login and returns the roles the user can be granted.

On receiving the login response, the DMZ server creates a dummy user (with a GUID for username and a dummy password), logs in that user, and grants the roles as sent by the back-end server. These roles are non-persistent, so that they won't be stored in the database (which is a good thing, as we only have a dummy user). Using these roles, the normal OutSystems role-based security can be used.

The reason we do not create an actual user is because as a customer portal, the server faces the interne, and we don't want any actual information on it stored in the database, so that in case we're hacked we don't leak any user information.

Nice use case Kilian, interesting the way it is using non-persistent roles.


I being advocate of automation, suggested to have roles in API response to use it as OS role. Indeed you should have this per session and shouldn't persist it. Additionaly user roles are mutable, so rely on API each session.