When you add an app to your OneLogin account, at first you can only configure simple options for your users. After this initial setup, more configuration options will appear.
The Portal section enables you to edit the app name, icons, and whether or not the app appears on the Portal. Personal or Organizational App selection determines whether the app appears in the list of company apps or personal only. The Connectors selection determines if this app will be configured through SAML or through a form.
After you save changes, more configuration options appear.
After the initial setup is saved, configuration options appear, including Info, Configuration, Parameters, Rules, Single Sign-On, Access Control, Provisioning, and Users.
Under the Info tab, you can update the app display name, visibility, icons, the tab it appears under in the list of apps, and any description or notes that you want to associate with the app.
Under Application Details, enter your main company domain name.
If you want OneLogin to provision Google Group and Organization attribute changes to G Suite, select Provision Entitlements. Note that if you do not select Provision Entitlements here but do enable provisioning on the Provisioning tab, OneLogin will pass Group and Organization attributes to G Suite upon initial G Suite user creation, but will not pass updated attributes to G Suite.
Under API Connection, the Authenticate button initiates the authentication process. Complete the authentication process on the vendor site.
The Parameters tab contains settings that allow for tight control over the OneLogin user fields that are mapped to specific fields within the application. This will allow which values within the application are mapped to specific values within OneLogin, and what entitlements are available for mapping to users in the Rules tab. This section affects both user field associations for the SSO tab, and for user provisioning.
The first section allows you to specify whether the credentials are solely admin-configured, or shared amongst all users.
Selecting one of these fields opens a small configuration pane, as seen below, where you can assign which value from OneLogin will be associated with the field in the application.
You can include the value in the SAML assertion as it is passed through, as well as include the value as the user is provisioned (if the application allows for provisioning).
Some values, such as Roles and Groups, will have an Edit Pane that contains the Name-Value relationship, but has been expanded to host two tables. This allows for a deeper level of attribute association, for example, a series of specific roles or groups that will be used in your organization. Below, you'll notice that the Role field can contain a variety of available roles for this application, but we've only selected the four values on the right to be associated with our users in our organization. By selecting Include in User Provisioning, these values will be then available for provisioning in the Rules.
The Rules tab allows you to create mappings. This set of options will allow you to configure a mapping that ties users or groups of users to specific attributes inside of the application, just as with entitlement and user mappings.
These applicationmappings can affect both the OneLogin roles and groupings, as well as entitlements and attributes that will be associated with the user or groups of users when provisioning occurs. These entitlements will come directly from the Parameters tab, and will allow values configured there to be mapped out to users.
Generate a new rule by selecting New Rule or select an existing rule to edit.
The example below shows an administrative mapping that makes all users that are a part of the 'Administrative Group' admins within Google Apps.
The SSO tab (single sign-on) contains the SAML endpoint information used to allow integrations with other applications. You can configure SAML SSO automatically or manually. In this section, you can also enable admins to assume or simulate users.
In the Enable SAML 2.0 section, on the Automatic Configuration tab, you can simply enable by using the toggle if all of the listed criteria are met.
If you switch to Manual Configuration, you'll find the currently associated X.509 certificate, the Issuer URL metadata, and both the SAML HTTP endpoint and HTTP Single Logout (SLO) endpoint.
In the Assumed Sign-In section, you may allow or disallow admins currently assuming a user to log in to those user's applications.
The Access tab contains controls that allow you to assign an app policy to roles. You can add role-specific policies, or apply a default policy across all users.
In the Policy section, select the policy you want to associate with the application.
In the Roles-Based Policy section, make a policy exception for the users in a specific role.
In the Roles section, choose the roles you want to associate with the application.
The Provisioning tab contains all options related to automating provisioning tasks. The top portion contains the Details and Workflow sections, where rules are defined as to how users are provisioned and de-provisioned within the application, while Entitlements just contains one option to Refresh Entitlements. If entitlement mappings have been moved to the Rules tab, where all entitlement mappings now exist.
Finally, the Users page shows all the users currently associated with the application and their provisioning state, if applicable. The provisioning state displays a color-coded backing to each user state: green for provisioned, yellow for pending, red if the provisioning failed, and unmarked if the user status is unknown. The list of provisioned users here can be filtered by roles, groups, and names.