How to use a source application's security model in a Sapho micro app

Audience: Developers building Sapho micro apps

Accessing data

Sapho’s ETN (Extract, Transform, prepare to Notify) process extracts active data from a source system, such as open purchase orders. The ETN process is much like the standard ETL (Extract, Transform, Load) process currently in place in many enterprise environments to load a data warehouse. Both Sapho’s ETN and typical enterprise ETL use an admin account of each source system to pull relevant data.

1_diagram-data-syncing.svg

There really is no feasible alternative to using an admin account to discover what information in a source system is relevant to an individual user. For example, to regularly check an SAP instance for new purchase orders, it is much more efficient to query once for all active purchase orders using an admin account, than to store each user’s username and password and perform an individual query on behalf of every user in the enterprise.

Limit access to data based on a user’s permissions

Just like a custom internal web application, Sapho micro apps can use customized queries to limit access to data based on a user’s permissions. For any authenticated user, authorization can come from three distinct sources:

  1. Groups for the logged-in user pulled directly from an Identity Provider, such as Active Directory.
  2. Roles from a source application (connector) mapped to the logged-in user.
  3. Custom authorization that is mapped to the logged-in user.

Using those authorization sources, Sapho provides two methods for restricting access:

  1. At the data level, i.e. you can filter results so that only permissioned records are available.
  2. At the functionality level, i.e. you can restrict access to apps.

Below are examples of how to restrict access and filter data using Google’s G Suite Identity Provider. Please contact your Sapho support representative for help using roles from connected services or a custom permissioning system with Sapho.

Functionality Permissioning by Restricting Access to Apps

Let’s say we have two applications - ‘Directory’ and ‘Directory Manager’. Both of these applications will look at the same underlying data source, but interact with the data in different ways.

In the ‘Directory’ app, users can scroll through the directory to see public information. We’ll show how to filter the search results in the section ‘Data Filtering at the Result Level’. This app will also have a button ‘My Profile’ that will only allow users to edit the information for their logged-in user. Since the search results are permissioned, and only the logged in user’s information is accessible, this app will be available to all users.

In the ‘Directory Manager’ app, the search results will show all users, and allow all fields to be edited. In addition, new employees can be added, and existing employees can be deleted. We will only allow authorized HR personnel to have access to the ‘Directory Manager’ app.

  1. Under the Security tab in Sapho Builder, choose your security provider, in this case G Suite.
    2_Security.png
  2. In Micro Apps with Access, activate the provider using the switch under Can Access, and then select the groups that can access each app by clicking on the icon in the Action column.
    3_Micro_Apps_with_Access.png

Data Filtering at the Result Level
In our ‘Directory’ app from above, let’s say that we want to filter out the ‘Employee Search’ results so that we only show users that the logged-in user has been authorized to see.

  1. Under the properties for any result set (e.g. List Properties), click Edit Query.
    4_ListQuery.png
  2. In the Query dialog, choose the Advanced tab and enter in your filter.
    5_AdvancedQuery.png
    For the filter, use an identifying key on each record specifying possible permissions. Then, only show the records where the logged in user’s mapped permissions contain that key. Below is an example using Groups from Google’s ‘G Suite Directory’:
     access_id in # Each result has a key showing the groups that can view it
    (select group_id # Select all group IDs for the logged in user
    from sapho_g_suite_directory.user_group
    where user_id = '{{userLogin}}')

Writing back to the source application

Sapho uses an admin account to the source system to execute service actions such as approvals. If the source system supports delegated authentication, Sapho can perform the action in the name of the user that triggered the action. If the source system does not support delegated authentication, Sapho can append a note to the record in the source system detailing who performed the action.

For certain compliance and information security reasons, it is critical that a user is logged in to the source application directly. In this case, Sapho can redirect the user to the target application with a deep URL that goes directly to the appropriate page within the application where the user can perform the action. In such a situation, there would ideally be SAML SSO set up for both Sapho and the target application so that the user does not need to have to log in a second time upon the redirect.

6_-_Mobile_Deep_Link.png