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.
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.
This page allows the Site Administrator to invite additional admins and edit existing ones. This page lists 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.
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.
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
Users can manage their cookie preferences from the User menu, by selecting Cookie Preferences:
The Details tab displays the user's name and email.
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.
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 Permission 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 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.
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 .
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):
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.
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
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.
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.
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
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: Data Field Permissions only apply to the following APIs (both REST and JS versions).
You can grant 5 levels of access to your schema:
Data Field Permissions only apply to the following APIs (both REST and JS versions).
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.
The license could not be verified: License Certificate has expired!
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.
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:
The license could not be verified: License Certificate has expired!
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.
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 US, EU, and AU datacenters), 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.
For other data centers, use one of the following:
- Russia: my.console.ru1.gigya.com
- China: my.console.cn1.gigya-api.cn
SAML IdP Settings
The IdP Settings form includes all the information needed to login to the console using your organization SAML IdP:
The Domain chosen (below) must consist of only lower-case letters. Using upper-case letters in this field will cause your login to not function.
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 Name - The first name mapping name on the IdP.
- Last Name Attribute Name - The 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.
Users that are logged in via Console SAML Login do not have access to their User Key and User Secret from the Account section of the Console.
- x509 Certificate - The IdP x509 certificate.
When you choose to manage permissions on the IdP:
- 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.
- 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 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 click 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.
Mobile devices are not supported on the Gigya Console or Gigya Documentation. To access the Gigya Console or view the Gigya Documentation you should only use a desktop/laptop computer with a supported browser.