Icecat offers different access policies for the users of the Icecat data. In this post we describe the key elements of our user access management.
The purpose of this policy is to prevent unauthorized access to Icecat’s cloud systems. The policy describes the registration and de-registration process for Icecat information systems and services. This policy applies to brand users, channel partners, Icecat staff, and system integrators.
In case that a product has the status “Publish: Limited”, its data is available only for so-called Authorized Resellers, users that are assigned to a specific brand, which are defined by the brand owner. The restrictions can go even further as a brand may give access to a particular product’s data-sheet only to one specific user from its brand-specific predefined authorized reseller list.
Brand Owners can define a syndication policy not just on product level, but also on the level of a Locale (country) for all products. Locale restrictions can be also set for just Open Icecat users or the whole Icecat user list via implies DRM. It can take into account blocking users from embargo countries.
Icecat offers brands Digital Right management (DRM) functionalities via its PIM. DRM is a set of functionalities to control which Icecat user is authorized to access and/or manage which information from which Locale.
On every product in the Icecat PIM, an editor can find the tab “publication restrictions” that shows what kind of restrictions are applied to the respectivec product.
Registration for Icecat is free of charge and any registered user can have access to the Open Icecat product catalog. The Open Icecat product catalog consists of the sponsoring brands‘ product data for their channel partners based on the syndication policies of these client brands.
Icecat monitors the market based on connected distributor feeds and covers other products that outside the Open Icecat catalog as well: the Full Icecat catalog with the product information for thousands of brands. Only Full Icecat users have access to the Full Icecat catalog.
To get access, a user needs to white list the IP(s) from which (s)he is accessing information, APIs and applications. It can be managed via the user account or by account managers. And any changes needs confirmation via a known communication address.
Icecat offers product information in 50+ different locales. The access of Icecat users can be limited to certain locales. As each local corresponds to a particular country, we can translate such restrictions to country level restrictions.
Access to Locales can be set by account managers.
According to a brand’s syndication policy, products may have digital assets (e.g., images, videos, PDFs, RTBs) that can be set as “Private” so that they are only available to their Authorized Resellers.
A brand has the possibility to indicate a Release Date per Locale for a specific product or digital asset. Only Authorized Resellers (or users) have access to the product data before the Release Date.
The End of Live date is also locale-based and has only an informative function for users.
To improve on privacy protection and online security, Icecat has implemented Two Factor Authentication (2FA) as an additional protection of a user’s account. More details regarding this functionality can be found here.
Access to the Icecat catalog can be limited for users to certain Verticals, i.e., the highest category level in Icecat’s taxonomy.
Access to Icecat information services is controlled through a formal user registration process. Each user is identified by a unique user ID, and any action they take is logged. Each account is secured by a password, 2FA (optional), and IP Filtering (mandatory).
Channel partners register solely through an online form, which provides them access to Open Icecat, the data of sponsoring brands of Icecat which is released for free access to the public/market. Open Icecat users will not get access to product data that is not yet released or which is marked as Private in the DRM system conforming the syndication policies of the respective brand to set Brand Restrictions, permisions for Authorized Resellers, Release Dates of digital assets, access to specified Locales etc. Only when a brand owener’s representative has indicated a user as an Authorized Reseller, the Icecat account manager will add this user privilege, and the respective user will get access to the Brand’s Private digital assets.
Icecat staff get users accounts and privileges conforming their position, which are disabled the moment they change their position or leave Icecat. Icecat Admin user accounts are obliged to be secured by 2FA as well.
Brand users are linked by their Icecat account manager to
their respective brand, and have access to the brands product data in the
Icecat PIM (backoffice) only.
The editor-in-chief controls the access level of Icecat
editors. The COO (team) controls the access levels of brand users. Account
managers verify and control the access levels of channel partners. The CTO
(team) controls the access levels of developers.
Changed requirements will normally relate to an alteration to the applications used but may also involve Brand/Reseller authorizations, upgrades or downgrades of editor access authorizations, Open Icecat or Full Icecat subscription levels of channel partners, etc. Requests are directed to the respective team director or account manager.
Change requests from channel users (by far the largest user group) are received through the Icecat ticketing system.
Where a user has forgotten his/her password, the system
supports them to request a new one without interference of the Icecat staff.
The cloud user accounts are never destroyed to be able to track historical information, but can be de-activated. As soon as Icecat staff leave the company all their accounts are de-activated. If Authorized Resellers are de-authorized by a brand, the additional access privilege will be removed from the brand record. If brand users change company, their accounts are deactivated or assigned to a new brand editor.
Network accounts can be deleted.
are those allowed to the system manager or systems programmers, allowing access
to potentially sensitive area. The unnecessary allocation and use of special
privileges is often found to be a major contributing factor to the
vulnerability of systems that have been breached. Privileged access must be
authorised by the Tech Director. The Tech Director will maintain a master list
of privileged accesses, which are in use, and this will be checked and
confirmed by COO on a three monthly basis. The list will identify all separate
logons for each system and service.
Users are advised to choose a so-called “strong” password. Additional IP Filtering is required for all users above the free Open Icecat user level. 2FA is required for users with Admin rights or the highest editorial privileges, and recommended for other users.
The COO will institute a review of all network access rights at least twice a year, which is designed to positively confirm all users. Any lapsed or unwanted logons, which are identified, will be disabled immediately and will be deleted unless positively reconfirmed. Annually, the COO will institute a review of access to applications, and for example a user’s access to Full Icecat and specific Verticals. This will be done in cooperation with the application owner and will be designed to positively re-confirm all users. All other logons will be deleted/deactivated.
The review is conducted as follows.
• The COO will generate a list of users, by application.
• The appropriate list will be sent to each application owner who will be asked to confirm that all users identified are authorised to use the system.
• The COO will ensure a response.
• Any user not confirmed will have his/her access to the
• The COO will maintain a file of lists sent over, application owner responses, a record of action taken, the review will normally be conducted Quarterly.
Read further: Manuals, Digital Rights Management, DRM, Icecat User Access Management Policies, PIM, user-friendly
Your email address will not be published. Required fields are marked *