Account Authorisation and authentication

Account Authorisation and authentication

  
Rather than use EnterpriseManager management/database.

How can an eSpace (application) use its own USER entity (tables) that consist of it's own username/password (columns) to facilitate the authorisation and authentication of a user account via the login and logout action? What must be set?
The following steps shows how you would share a USER entity table between eSpaces
1 - Create a eSpace and set "User provider eSpace" to yes.
2 - To share permission area between eSpace, set "Public" property for the permission area to Yes (via the User Provider eSpace).
3 - create another espace and select the user provider espace that you created in step 1,
4 - select add/remove reference, then click on the user provider espace, now add the user permission/roles.

done.

This works, however there seems to be no solution for creating and using your USER entity table?

Hi Robert,

 

 

Not sure I understood your need.

 

If you do nothing, your eSpaces will use their own USER entity table (this corresponds to having the User Provider eSpace property set to "(Current)").

 

When you create an eSpace and set it as User Provider, you are saying that eSpace (step 1) and all the ones that use it as User Provider (step 3) will share a given USER entity table, therefore having the same group of users and authentication mechanisms.

 

The fact that eSpaces reference the same system USER entity table may be confusing... In fact, the USER entity is a multitenant entity, that is, it is prepared to have partitioned data per eSpace. So despite all eSpaces having a reference to the USER entity, in fact when you query it, only the data that the eSpace is configured to see will be returned. If the eSpace has the User Provider eSpace set to "(Current)", queries and authentication mechanisms will apply only to the set of users that belong to that eSpace. If the eSpace is using another one as User Provider, the same applies for a different group of users.

 

Was this somehow clear? Cheers,

Hi Rodrigo

Thanks for answering my question -- everything was understood clearly

Sorry for not being clear, I would like the eSpace to use my own "self" "created" entity table.

Just for an example I create a new entity table and titled it "DEVELOPER", I then add two attributes columns: Username and password, etc

I now would like my eSpace to use the "DEVELOPER" entity table to authorise and authenticate user's signing into this eSpace. i.e I wish not to use the default USER entity table, that has been added by Outsystem Service studio. I prefer to link Outsystem Service Studio to my own table, but unable to do this? Technically this is possible but there is currently no option to allow for this? (not that im aware of anyways)

Amongst other reasons, the main reason is... I like to add my own attribute columns to the "USER" table that is used to authorise and authenticate the user but I'm unable to do this (ie the USER entity table has been greyed out).

Hi Robert,

 

 

Ok, got it now! To support your need, the User entity has an attribute Extension_Id which you should use to reference a record of an entity that extends the User entity. The general idea is the following:

  • Create an Entity with all the attributes you need for users, let's name it User_Extension
  • Then, whenever you create users in your app, you create also a record in the User_Extension entity and set User.External_Id to be the Id of the User_Extension you just created
  • Afterward, whenever you need to get the user attributes of your User_Extension entity, all you have to do is join it with the User entity

Check the attached oml for a sample. Hope this helps, cheers.

Rodrigo,

understood thanks, and thanks for the example espace.
Rodrigo,

About eSpace and the USER entity

If you create 3 eSpaces -eSpaceDeveloper
-eSpaceEmployee and
-eSpaceCustomerVendor

Each eSpace will have its own USER entity which are not shared between eSpaces.
Now you want to create another eSpace "eSpaceManager" and you want this eSpaceManager to see all the user's information inside the USER entity from all 3 eSpaces as stated above.

how would you go about doing that?
I guess the easiest (and maybe the only way to do it ?), is you can make all 3 eSpace use a common User eSpace Provider, this would solve the problem stated above.

However if you do not wish to do this, is there another solution?
(i.e You want to keep all 3 eSpaces USER separated (ie stored under a seperate USER table) but you like the Manager to see the USER data from all 3 eSpaces).

Hi Robert,

 

 

Well, the "best" solution actually depends on your business scenario.

 

Do all those eSpaces belong to the same portal? If so, you should consider using a unique User Provider for all users, and then use Permission Areas, or Roles, to segment users (Developer, Collaborator, Customer...). If they all belong to the same portal, I guess it would make no sense to keep them as separated users.

 

Have you tried Enterprise Manager? It already provides you with a user management back office, login architecture, roles, company hierarchy and some more stuff. You can use Permission Areas as Privileges in your eSpaces to do particular actions, and then create Roles in Enterprise Manager to group such Privileges. This way you can create a Developer Role which has different Privileges than a Customer Role. In your eSpaces you can then segment what each Role can do and in Enterprise Manager you can see and configure which users belong to each Role. You can learn more about Enterprise Manager in the Academy, specifically in the last two lessons of the Developer Course 2.

 

On the other hand, if you are attempting to create some sort of multitenant portal, where the same app would serve different user sets (for different companies, for instance), then there are different solutions for that scenario. Is this the case?

 

 

Cheers,

Rodrigo,

I had a look at EnterpriseManager and it seems like we might have to build our own version of EnterpriseManager (prefer not to but it seems to be cleaner option).

(I send you an email if you like-; prefer not to post information regarding project on a public forum).

cheers