Implementing SaaS User Management

Overview of SaaS User Management

Oomnitza is now offering the possibility to manage how and when users are leveraging various SaaS Systems within an organization. The supported SaaS systems include Jira, Salesforce, Zoom, Zendesk and many others - Oomnitza intends to steadily grow the list of supported systems.

Oomnitza SaaS management module enables user management by tapping into an organizations Single Sign-On (SSO) solution(s) with an Oomnitza instance, to access the SSO records. Once Oomnitza attains the SSO records, it is able to integrate with respective SaaS Systems directly, thus resulting in a user management capability yielding a better understanding of what users are doing within the system(s).

User management reaps many benefits, including freeing up licenses that are either unused or require termination upon a user leaving an organization. License management significantly improves security and compliance, and reduces the cost organizations pay for SaaS Systems, which are often licensed based on quantity of users leveraging the service.

This article is divided into three sections, which describe the pre and post implementation method for Oomnitza SaaS User Management, as well as the various workflows used to manage SaaS Users effectively.

Section 1: Best Practices, Pre-Implementation

Section 2: Best Practices, Implementation

Section 3: Best Practices, Ongoing Maintenance

 

Section 1: Best Practices, Pre-Implementation:

  1. Enable SSO: Oomnitza strongly recommends that SSO is enabled in a respective SSO Service, to efficiently use Oomnitza SaaS User Management. Oomnitza currently supports integrations with GSuite, Azure, Okta, and OneLogin. Although an organization can leverage Oomnitza to manage SaaS Users without SSO being enabled,  this is often a tedious, manually intensive process.

  2. SSO For User Creation: Oomnitza recommends limiting access to SaaS Systems to SSO only, thus disabling user access to the SaaS systems via username and password. 

  3. SaaS Software Contract Repository: Oomnitza recommends creating a consolidated list of SaaS Software contracts within the organization, prior to commencing implementation of Oomnitza SaaS User Management. Although this is not a hard requirement, it enables easier contract management for the SaaS Systems, cost modeling for the SaaS Users, and understanding of contracts in possession, which are missing, and other appropriate information.

  4. SaaS System API Access: Oomnitza recommends requesting API access to in scope SaaS systems, since API permission allocation may take some time depending on an organization. API access is required to manage users - as an example, being able to delete a user from the respective SaaS System.

Section 2: Best Practices, Implementation:

Oomnitza SaaS User Management implementation is composed of the following steps, in order: 

  1. Enabling SaaS Management Integration
  2. Creating and Uploading SaaS Software Contracts
  3. Removing Unnecessary Software
  4. Prioritizing SaaS Software
  5. Configuring the Workflows for SaaS User Management
  6. Configuring SaaS User Load Connectors

1. Enabling SaaS Management Integration

Prior to leveraging the SaaS module, a SaaS integration between Oomnitza and the chosen SSO is required to properly populate the module. To learn how to populate, setup and configuration the SaaS module, please visit Oomnitza's article on Setting up the SaaS Module.

When enabling Oomnitza SaaS Management integration, ensure that the naming convention is in sync with Oomnitza user integration. This will prevent creation of redundant users in Oomnitza. In addition, it is important to assign the default role equivalent to "Employee" or a similar limited authorization role.

The SaaS System sync will be triggered on the set scheduled run, or can be manually triggered by clicking Run Now in the UI.

Note: Oomnitza has added the ability to create SaaS Software manually. Manually created SaaS Systems will not be linked to any external system (such as SSO) but can be linked to contracts - Thus, can still utilize the suite of automations available in Oomnitza's Workflow Engine.

2. Creating and Uploading SaaS Software and Contracts

After retrieving details on SaaS software from the SSO solution, create and/or upload the SaaS Software contracts. Contracts can either be created manually, or uploaded via a .csv file in Oomnitza. This is done by allocating the appropriate Contract Type and matching the SaaS Software name to the corresponding software in Oomnitza.

Although this may be considered a time consuming step, initially uploading as many SaaS Software contracts as possible enables organizations to benefit from many downstream Oomnitza SaaS Management features.

3. Removing Unnecessary Software 

The average Organization uses anywhere from 25 to 200+ different pieces of SaaS Software. These can vary wildly in price and number of users.

After finalizing the SaaS Management Integration, the discovered list of SaaS Software may contain many unfamiliar pieces of SaaS Software. Oomnitza recommends removing the unneeded SaaS software, prior to enabling more advanced Oomnitza SaaS Management features. This can be done by either ignoring or archiving* the unneeded SaaS Software. The SaaS Software list is often longer when using GSuite for SSO, since many sites offer SSO with GSuite. Whereas other SSO solutions require certificates exchange before granting SSO access to applications.

Note*: There is a difference between ignoring and archiving the unneeded SaaS Software. Ignoring the SaaS Software will not account for current or new active logins that come in. Archiving will remove the SaaS Software, however, if a new SSO record comes in it will be activated again. A general rule of thumb is:

  • Ignore: If a SaaS software is being used by the organization, but is free and/or not important to track
  • Archive: If a SaaS software is no longer being used by the organization

4. Prioritizing SaaS Software

After ignoring or archiving unnecessary SaaS Systems, Oomnitza recommends organizing the  comprehensive list of actively used SaaS Systems and respective users that have logged into the SaaS systems through SSO in the last 6 months*.

Oomnitza advises prioritizing and identifying the top SaaS Software by several parameters, including number of users, cost, and importance (or a mixture of all three). This process will assist with identifying the most important SaaS Systems, thus enabling configuration of efficient workflows.

Note*: There may be gaps in the system and user data. If this is the case, the current workaround is to manually add all active users within an organization to the SaaS System. This will allow the SaaS User Role workflows (see below) to take care of finding the active users in Oomnitza.

The users will be missing if the following conditions are true:

  • The SaaS User has not logged into the SaaS System
  • The SaaS User has not logged into the SaaS System via SSO for 6+ months
  • The SaaS User has not logged into the SaaS System via SSO, rather leveraging their local username and password
  • The SaaS Systems are not SSO enables

Oomnitza plans to develop additional integration points with SaaS vendors in future release(s), in order to overcome the above limitations. 

 

5. Configuring the Workflows for SaaS User Management

Note: Unlike other workflows in Oomnitza, the workflows for SaaS Users run for both active and deactivated records

Prior to configuring workflows, it eminent to achieve a complete mirror of users across the identified SaaS Systems, to allow proper management of users in Oomnitza. This will eliminate the need to manage users individually inside of each SaaS System, as Oomnitza can detect users that have been added and deleted in the SaaS System and update the SaaS System, by leveraging workflows.

As an example, if a user is deactivated within Oomnitza a user deletion function will be triggered within the SaaS System. Additionally, the SaaS User record will be deactivated in Oomnitza and assigned a flag "Delete User in SaaS", meant to ease user identification.

Oomnitza recommends leveraging several workflows that ensure the SaaS users in the SaaS Systems stay in sync with the SaaS Users within Oomnitza.  The below "best-practice" workflows should be set up for all relevant SaaS Systems, as this allows assignment of individual rules for each SaaS System workflow*.

  • Workflow 1: SaaS User Role Workflow
    • Read user details from a specific SaaS System
  • Workflow 2: SaaS User Delete Workflow
    • Delete user from a specific SaaS System, to eliminate potential reassignment of resource in the SaaS system
  • Workflow 3: Reclaim Inactive SaaS User Workflow
    • Identify and remove inactive users from a specific SaaS System, by looking at their last login date
  • Workflow 4: Employee Off-boarding Workflow
    • Identify all the active SaaS Systems and Contracts assigned to a user, and remove them

Note*: Oomnitza is readily working on expanding the list of SaaS Systems with capable API connections. In the case an identified SaaS System, which provides APIs, is not supported, please submit a feature request. 

Workflow 1: SaaS User Role Workflow

Intent: Read user details from a specific SaaS System

Output:

  • Verification that user still exists
  • The user's role(s)
  • The last login date

Note: The availability of role details and last login timestamp depends on the available APIs in the respective SaaS System. Please review the SaaS System documentation for more information.

Begin Block Criteria:

Oomnitza recommends running this scheduled daily workflow for all active users, in a given SaaS system. The Rule Criteria in the Begin block should be configured as such:

mceclip0.png

Since SaaS User Workflows can run for both active and deactivated records. This can be circumvented by specifying "Run for active records" in the begin block to not overload the SaaS System, as well as Oomnitza.

Block Configuration:

The SaaS User Role Retrieval block should immediately follow the begin Block. The block should specify a given system and include credentials that can be picked from the vault to access that system.

 

Workflow 2: SaaS User Delete Workflow

Intent: Delete user from a specific SaaS System, to eliminate potential reassignment of resource in the SaaS system

Note: Prior to deleting a SaaS user it is important to "clean up" the user in the respective SaaS system(s). For example reassigning opportunities in a CRM to the user's manager, reassigning folders to another user, etc.

Output:

  • Off-boarding Notification
  • Deleted User in SaaS System
  • Archived User in Oomnitza

Begin Block Criteria:

Oomnitza recommends running this scheduled daily and/or hourly workflow for all users, in a given SaaS system to ensure a timely deletion. The Rule Criteria in the Begin block should be configured as such:

  • that the field User identifier in SaaS has a value
  • SaaS Users that have set the flag "To be Deleted in SaaS" set to Yes
    • Note: Depending on the SaaS System, you may deactivate or delete the user
  • SaaS Name set to the given SaaS System 

mceclip1.png

Block Configuration:

  1. Include an API block to delete the user in the SaaS System. To do so, leverage Oomnitza's API blocks with presets, available for the respective SaaS Systems.
  2. Include an update block to set the “To be Deleted in SaaS” field to No.
  3. Include an Archive block to deactivate that user in Oomnitza.

Note: It is possible to communicate the off-boarding of a user or re-assignment of items to respective users, by leveraging the notifications, or slack blocks. 

 

Workflow 3: Reclaim Inactive SaaS User Workflow

Intent: Identify and remove inactive users from a specific SaaS System, by looking at their last login date

Output:

  • Off-boarding Notification
  • Deleted User in SaaS System
  • Archived User in Oomnitza

Begin Block Criteria:

Oomnitza recommends running this scheduled daily and/or hourly workflow for all users. The Rule Criteria in the Begin block should be configured as such:

SaaSUser_Begin3.jpg

LastLoginDate “Days Before” 60 (or whichever number of days you allow a user to be inactive)

Deactivated equals No

SaaS Name set to the given SaaS System 

Note: If 60 days of inactivity is the basic rule for all SaaS System within an organization, only one workflow needs to be configured. Otherwise, create a single workflow per SaaS System to reflect different users inactive periods.

Block Configuration:

  1. Include update block to set the field "Delete User in SaaS" to Yes
  2. Workflow 2 (SaaS User Delete Workflow) will activate and properly remove the user from the SaaS System

Workflow 4: Employee Off-boarding Workflow

Intent: Identify all the active SaaS Systems and Contracts assigned to a user, and remove them

Note: Create this workflow after defining the workflows for each of the managed SaaS Systems 

Output:

  • Removed User from Contract assignment
  • Deactivated User in SaaS Software
  • Off-boarding Notification
  • Deleted User in SaaS System
  • Archived User in Oomnitza

Begin Block Criteria:

Oomnitza recommends running this scheduled daily and/or hourly workflow for all users.

Block Configuration:

  1. Include the License Off-boarding workflow block
    • Enable the option for automatically removing all SaaS licenses, to remove user from all active SaaS Software and Contract assignments.

OffboardLicenses.jpg 

When the workflow is run, the flag "Delete User in SaaS" will be updated to "Yes", Workflow 2 (SaaS User Delete Workflow) will activate and properly remove the user from all the SaaS Systems on the next scheduled workflow run.

6. Configuring SaaS User Load Connectors

In order to gain a complete view of the data available from a SaaS software, it's vital to also include a SaaS User Load Connector for each of your managed SaaS Softwares. SaaS User Load Connectors allow Oomnitza to fetch a list of all users from your managed SaaS Softwares. By combining this with the list of active users retrieved from your SSO Integration, you can identify users who have accounts in your SaaS system, but are not logging in through SSO.

 

Tip: We recommend that you start by only selecting the SaaS User Load to 'Update' users as opposed to 'Create and Update' as this will allow you to see the information being retrieved without creating potential noise into your environment. Some SaaS instances will retrieve all users that have been part of the SaaS, including users that are no longer with your company or users that are no longer using the software. 

By looking into the results of the SaaS Sync you can see what users were skipped due to the connector settings and this can help you determine the data hygiene of the SaaS Software you are integrating with. Once you have reviewed and are satisfied with the data, you can update the connector settings to 'Create and Update'.

 

Configuring SaaS User Load Connectors

SaaS User Load Connectors are only available through the extended connector framework, and are set up much like regular connectors. The process of setting up a SaaS User Load Connector is much the same as setting any other User connector, however, when configuring the connector, from the "Connect" page, select "User plus SaaS User" from the User Selection Dropdown.

mceclip0.png

The rest of the connector can be set up just like any User connector. Full instructions on connector setup can be found here: Extended Connectors.

 

Section 3: Best Practices, Ongoing Maintenance:

After the initial implementation of Oomnitza SaaS User Management, it is recommended to periodically review of the users, contracts and SaaS Systems in Oomnitza. This will ensure that:

  • Users were not created manually in Oomnitza
  • Contracts and SaaS Systems details are correct (renewal dates, license costs. etc.) in Oomnitza

 

 

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk