Console Administration

Skip to end of metadata
Go to start of metadata

Introduction

Gigya provides a general framework for setting and enforcing user and application level permissions.

The permissions system enables you to create users (user keys), grant them permissions, and evaluate their permissions upon incoming requests. The permissions determine which API methods the user can call, what parameters the users can pass, what the valid values for these parameters are and what types of logical operations are allowed. In addition, permissions are scoped to certain partners or sites.

Watch an Instructional Video

If you have a Gigya Academy membership, you can watch instructional videos about this and other Gigya products. To access Gigya Academy content, you should first make sure you are logged into the Gigya Console

Gigya Academy is a premium product that requires separate activation. If it is not part of your site package, please contact your Account Manager or contact us by filling in a support form on our site. You can also access the support page by clicking "Support" on the upper menu of Gigya's site.

To watch a video about Console administration, Gigya Academy members can use this link.

Console Administration

To manage administrators and user groups, first sign into the Gigya Console at https://console.gigya.com, and click the "Admin" tab in the top right panel.

Manage Administrators

This page allows the Site Administrator to invite additional admins and edit existing ones. This page l ists all the admins associated with the current client site(s):

For each user, the table displays the user's Name and E mail and the Groups the user belongs to. Under Settings, th ere is an edit button (see  Edit User ) and a remove button.

Invite Administrator

In order to add an admin, click the "Invite Administrator" button just above the table. In the dialog box that opens, fill in the new user's email and select the group.

When you are done, an invitation is sent by email. Note that the email invitation expires 72 hours after it is sent.

Edit User

To edit a user, click the edit button under "Settings" in the table.

This opens the Edit User page, which includes three tabs:

  • Details - shows the user information
  • Groups - lists all the available groups for the partner
  • Resolved Privileges - lists the privileges for the selected user

 

Details Tab

The Details tab displays the user's name and email.

Groups Tab

The Groups tab lists all the available groups for the partner, including the groups to which the user is assigned and the ones to which the user is not assigned.

As an admin, you can use this section to delete the user from a group or add the user to one. To add the user to a group, click "Assign Group" and add the user to the selected group:

 

Resolved Privileges Tab

The Resolved Privileges tab displays the list of privileges for the selected user:

The table displays the list of resolved privileges per site. Read more about Privileges.

Manage Applications

This page allows you to create, remove and edit "application keys" - credentials that are given to third-party applications to enable them to access the Gigya platform and make system calls. An application key is, in fact, a special type of user key, which is not associated with a specific user. When you add a new application, you create a user key without requiring a user registration flow. Application keys have higher rate limits than standard user keys, but their actions are not audited.

To grant applications specific permissions, you assign the applications to a user group, either at the time of the creation of the application key, or through the Manage Groups page. As an application is assigned to one or more groups, it gains the permissions defined by that group and is able to make API calls to Gigya based on those permissions.

For more information on managing permissions for applications, please contact your Implementation Consultant.

The Manage Applications page lists your applications with the group(s) each application belongs to. Under Settings, you have an edit button and a remove button for each application. Above the table are the main function buttons: Create New Application and Add Existing Application.

Create New Application

When creating a new application, you are required to name the app and select a group to include the new app in. This group can later be removed, or other groups can be added through the Manage Groups tab.

Once an application is defined within Gigya, it is provided with a special User Key and a Secret. These credentials are used as authentication and authorization when making system calls to Gigya later on - similar to the API key and Partner Secret functionality. To see these credentials, click the application's name in the main table and go to the Details tab.

Add Existing Application

Adding an existing application is a way to grant access and permissions to an existing application that is not a part of your site, such as a third-party service that you want to enable to make Gigya system calls on your site.

When adding an application, you are required to provide the application's User Key, and just like when creating a new application, you need to select an initial group. Once the application is added to your admin panel, you can add or remove it from groups using the Manage Groups page.

Permission Groups

This page lists the user groups, which determine the permissions or privileges given to each user key and application key. The page allows you to add or remove groups, edit the members of each group and define the privileges that are granted to members of that group .

 

Create Group

To create a new group, click the Create Group button above the group table. In the dialog box that opens, fill in the new group's name and description (the description is optional):

 

Duplicate Group

To duplicate a group - i.e., to create a new group with the same permissions - click the Duplicate button next to a specific group's name.

The Create New Group dialog box will appear, where you'll be able to fill in the new group's name and description.

Edit Group

To edit a group, click the Edit button next to a specific group's name.

The Edit Group page opens, containing the following tabs:

  • Privileges - lists all the available permissions and allows the admin to enable/disable privileges
  • Members - lists the users and applications assigned to the specific group and allows the admin to add or remove members from the group.
  • Scope - shows the list of sites enabled for this group

Privileges Tab

The Privileges tab displays all the available privileges and allows the admin to enable/disable privileges for the specified group:

Privileges are divided into categories and are mapped to allowed API methods. See the Privileges section for the list of categories and full mapping of privileges to APIs.

To add or remove a group from a privilege, check or uncheck the privilege from the list. The change will take affect only after you click the "Update" button.

Members Tab

The Members tab displays two tables. The first table lists the admins assigned to that specific group, and the second lists the applications assigned to the group.
Site admins can add or remove group members by clicking the corresponding 'Add to group' button at the top of the table.

For each user, the name, title, and email are displayed. For applications, the application name is displayed.

Clicking the corresponding Add button will open a dialog for selecting the users/applications you wish to add to the group.
 

 

You may also delete a user or an application from the list.

Scope Tab

The Scope tab displays the list of sites that are enabled for this group:

You can choose one of the  two radio buttons, to either include or exclude the listed sites. The change will take affect only after you click the "Update" button.

 

Data Field Access

This parameter or feature is part of our Early Adopters Program. To find out if you are eligible for participation, contact your Account Manager by filling out a support form. You can access the support page by clicking Support on the upper menu after logging into your Gigya Console

The Data Field Access tab of the Permission Groups section of the Admin panel allows you to restrict access to specific fields of your schema based upon permissions of the user or group accessing them.

You can grant 5 levels of access to your schema:

  • No access to any fields
  • Full access to all fields
  • Specific access to defined fields
    • Read-only access to specific defined fields
    • Write-only access to specific defined fields
    • Read and write access to specific defined fields

 

For additional information see Data Field Access.

 

List of Privileges

The following table displays the available privileges. Each privilege grants access to certain API methods.

 

Notes: 

  • When the Full API Access privilege (External Integrations) is assigned it overrides all other permission settings on this page, any user assigned to this group will be considered an Admin and will be able to call any API method using their user key/user secret without requiring the use of a partner secret. This allows for more accurate auditing as well as more granular privilege assignment/revocation. This privilege is automatically assigned to all users in the _admins group.
  • Gigya's Roles and Permissions mechanism supports data permissions, effectively limiting the data accessible via API calls. For more information regarding this feature, please contact your Implementation Consultant.

 


Audit Log

This page allows site administrators to view a log of all actions performed by users and administrators via the console or via certain REST APIs. The complete list of audited APIs can be found below.
Although all audited events are logged, they may not appear in the Audit Log if the user/group viewing the page doesn't have the necessary privileges. These privileges may restrict viewing items at the site level, or allow viewing items on a global, partner level. 

 

The Audit Log is a feature of the 'Identity Enterprise' package, which is a premium service that requires activation. If it is not part of your site package, please contact Gigya  Support  via the  Console .

 

Click on a log item to expand it and display extended information:

           

For more information, see Using the Audit Log.

Console SAML Login

Gigya's console supports Secure Assertion Markup Language (SAML) 2.0, which allows you to login to the console using your organization SAML Identity Provider (IdP). The console, as a single site, will use Gigya's SAML Login implementation (Gigya as a Service Provider) for connecting to IdPs. In order to do this, you must configure the SAML IdP settings. 

Sign into Gigya's Administration Console and  click the "Admin" tab in the top right panel, then click the "Console SAML Login" tab in the left menu:

 

 

Notes: 

  • A user connecting to Gigya via SAML SSO can not be associated with more than one partner. Even if the user is the same user at the IdP, he will be considered as a different user when connecting to two different partners at the Gigya Console.
  • Login to the console via SAML when the request is initiated from the Idp is not currently supported.

 

Managing IdPs

The console allows a partner to configure one IdP for the partner account in the partner administration section. The IdP configuration includes attribute mapping that map IdP response fields to user identity fields. 

SAML SSO configuration is available only to site admins.

Landing Page

The page through which SSO is performed for the IdP is called the domain, or the "landing page". The full unique URL of the page is the domain with the "my.console.gigya.com" suffix, for example, https://<customdomain>.my.console.gigya.com. The server validates uniqueness for the <customdomain> part of the landing page URL by a unique index. When a user reaches the landing page, the server will query the partner configuration according to the custom domain to know for which partner ID it is used.

SAML IdP Settings

The IdP Settings form includes all the information needed to login to the console using your organization SAML IdP:

 

The input fields are as follows:

  • Domain - The URL of the page through which SSO is performed for the IdP - the landing page.
  • Issuer - The Identity Provider’s entity ID.
  • Single-Sign-On Service URL - The Identity Provider’s SSO URL.
  • Single-Sign-On Service Binding - The type of SSO binding.
  • Single Logout Service URL - The IdP’s SLO URL.
  • Single Logout Service Binding - The type of SLO binding.
  • Name ID Format - The format of the nameID.
  • User Email Attribute Name - The user email mapping name on the IdP.
  • First Name Attribute NameThe first name mapping name on the IdP.
  • Last Name Attribute NameThe last name mapping name on the IdP.
  • Manage Permissions on Console - Select this option to maintain and manage user permissions within the console. Once the user has been created, the console admin can add or remove permissions by association to permission groups via the console Manage Groups page.
    • Initial Permission Group - Users will be associated with this Gigya permissions group upon their initial login. By default, users will be added to the 'no permissions' group which has no permissions. Users of this group will not be able to access the console, until they are associated with an appropriate permission group by an admin.
  • Manage Permissions on IdP - Select this option to manage the permissions on the IdP. Gigya will receive user permissions by the IdP on every login. When choosing this mode, users with no permissions will not appear in the console's Manage Groups tab, as their group association is not managed by Gigya.
    The attribute in the IdP response may contain several values. Each value is treated as a separate group and mapped to the appropriate user group, so a user can be assigned to several user groups. Unmapped groups will be ignored. If no mapped value is returned in the response, the user will be placed under the default group.
    • Default Permission Group Users will receive the permissions of this Gigya group when no mapped value is returned in the response. By default, users will be added to the 'no permissions' group which has no permissions. Users of this group will not be able to access the console, until they are associated with an appropriate permission group by the IdP.
    • Idp Attribute Name for Permission Group - The Identity provider's attribute name for the permission group.
  • Group Mapping - The mapping of the IdP groups to the Console groups.

    You can only map a user to a single Gigya group. Mapping to multiple groups inside the Gigya Console is not supported.

  • x509 Certificate - The IdP x509 certificate.

 

When you choose to manage permissions on the IdP:

  1. The attribute in the IdP response may contain several values. Each value is treated as a separate group and mapped to the appropriate user group, so a user can be assigned to several user groups. Unmapped groups will be ignored. If no mapped value is returned in the response, the user will be placed under the default group.
  2. The user groups are updated according to the groups from the provider on each login. In this case, there is no point in administrating permission groups for the user via Gigya, since the changes will be overridden on the next login.

SAML SP Metadata

View the console SAML Service Provider (SP) metadata, by clicking the link. This metadata ensures a secure transaction between the Identity Provider (IdP) and the Service Provider (SP). 

The metadata on this page presents the SP details that are required for the SP configuration at the IdP service side. These values cannot be edited, and are included solely for configuration at the IdP:

User Keys

User keys are used to grant individual permissions to certain users on certain sites. User keys are more secure than giving all users the partner secret key, which grants full permission to all data and actions on the API key, including the ability to delete user data. In addition, actions taken using the user key are tracked for auditing purposes.
 

As a site owner, you can grant API access to your employees or to third parties with fine-grained permissions to perform tasks such as moderation, administration, data access etc., and with no more permissions than necessary. All actions that can be performed using the console can also be performed using the Gigya API, with a user key and secret passed along with the request.

Users are typically created in these scenarios:

  • The Gigya platform associates every new user to a built-in group based on his role(s) (e.g. site administrator, content moderator).
  • Identity management products based on Gigya, which clients create using the Roles & Permissions APIs, may manage their own privileged users. 

A user may have access to multiple sites and multiple partner accounts. After creating a user, you can set permissions for that user across all sites that the user has access to, via the Gigya Administration Console or using an API call. Account administrators can grant a user various permissions on their sites through the Gigya Console's Manage Groups page, or programmatically by issuing a REST API call that updates groups, using the account admin's user key and secret, and passing a target user key to which to grant privileges.

Making API Calls with a User Key

To make API calls with the user key instead of a partner secret, see Using the Gigya API with a User Key.

Finding Your User Key

As a console user, to find your User Key, you must first sign into the Gigya Console , and then c lick your name at the top right hand corner. Select "Account" from the drop-down menu.

This opens an Accounts Settings page where you can find your User Key.

 

To download the video, click here. If you are having trouble viewing the video, please see Video Help For Gigya Documentation.

Note: The User Key is personal and should not be shared with others. Each console user has their own user key and should only use the key assigned to them.