FTID Identity and Access Management This document defines requirements of FT Interactive Data's needs from an IAM solution. In context of this document, IAM is defined as a strategy relating to managing identities of clients and employees. An IAM solution should cover: ¥ Management of data structure, including definition of business and technical rules ¥ Storage of identity-related data ¥ Authentication of users ¥ Enforcement of business procedures ¥ Management of user data ¥ Integration into existing systems, including efficient accessibility FTID Requirements The requirements of FTID are divided into 3 areas: data structure management, data management, and data access. Data Structure Management includes: - Defining FTID services - Establishing rules for provisioning for defined services - Progressing data structure Data Management includes: - Role based provisioning - Request/Authorization queues - User reporting - Data replication - Audit reporting Data Access includes: - Flexible, secure, high-volume programmatic access to data - Software integration into various provisioning options Data Structure Management Define new services FTID maintains multiple services, which must be definable. As new services become available, select internal users must be able to add and define these new services. For each service, it is desired that administration of that service may be assigned to specific individuals within FTID. Example: FTID creates a new web service 'SuperPrice', which requires maintenance of client accounts. Adam (internal administrator of IAM) creates a record of this new service using an IAM interface, and assigns Sarah as the administrator of 'SuperPrice' service. Create/modify/remove service settings Each service contains within it a multitude of settings for clients or internal users. These settings may be of varying types, and be governed by different degrees of logic. The settings must be managed (added, modified, deleted) by service administrators. Example: SuperPrice has a premium setting for users which gives a particular user certain additional data when activated. Sarah creates a new setting for SuperPrice called 'Premium'. She defines it as a Boolean (on/off) setting, and specifies that the default value for this setting should be 'off'. Settings may be of varying types, such as: - Boolean (on/off) - Text (varying size) - Numeric (varying size) - Single-select multiple-choice - Multi-select text - Multi-select numeric - Multi-select multiple-choice - Single-select user Note, above, 'Single-select user' indicates that it's effectively a 'Single-select multiple- choice'. However, that value translates to a separate user. For example, SuperPrice has a 'Single-select user' setting called 'Support Contact'. Further, SuperPrice has a separate Boolean setting for internal users called 'Support'. Scott is an internal user who has 'Support' turned on. For a client 'ABC Bank', their 'Support Contact' may be set to 'Scott'. Settings must be able to have a wide variety of availability rules defined for them. These rules dictate when a user is allowed to have a particular value set. Example: SuperPrice has a text setting called 'Conversion Rate'. However, 'Conversion Rate' is only available to users who have 'Premium' turned on. Settings must be able to have modification rules defined for them. These rules dictate which users can (and under what circumstances) modify certain settings. Settings must be able to have default logic defined. This logic may specify the default value, or the format of a default value. Settings must be able to have restriction rules defined. This logic may detail the allowable format of values that are entered for this setting. Example: 'Conversion Rate' is only modifiable by Sarah. The default value for 'Conversion Rate' is 'ax100'. The setting is restricted to be two alphabetic characters followed by any number of numeric characters, including decimal values. Note Ð restriction rules should be followed for newly entered settings, but should not necessarily be enforced for existing data when initially fed into the system. Additional logic may include caveats such as "a user may have a particular value set for up to 90 days, after which it is adjusted to another value, assuming no administrative intervention. Some settings may also be subject to a request queue, allowing non-authorized internal users to request a value for a particular setting, which is then approved by authorized internal users. Example: Scott wishes to set 'ABC Bank' to be 'Premium'. Scott cannot modify the value of 'Premium' himself, and so creates a request for it to be set. Sarah receives the request (notification via email preferred), examines it, and approves or denies the request. Scott may similarly be notified of the request status when it changes. Progress Data Structure FTID follows several levels of release from development to production. The IAM interface must allow that data structure to be delivered from one environment (such as development) to another (such as production) upon request. Further, the ability to revert to a previous version of the data structure is also required. Example: The current structure in the development environment (version 2.0) for SuperPrice contains the 'Premium' setting, while the production environment (version 1.0) does not. For the subsequent release of SuperPrice, Adam releases the service structure to the production environment, and now both development and production environments contain the 'Premium' setting. However, due to a release problem, version 2.0 does not work. Adam therefore reverts the production environment to version 1.0, and the production environment no longer has the 'Premium' setting. Data Management Data will be managed by internal users, but also by clients in a limited capacity. As a result, systems for managing that data should be accessible externally, most likely through a web-based utiltity. User Reporting Tools for viewing user information must be available, and should support: o Individual client views o User lists according to search parameters o Search utility for locating users These tools should respect rules established within the data structure, and grant view access only to those users who are authorized to view particular data. Create/modify/remove user entries User entries must be added, modified, and removed according to the rules established within the data structure. Roles defined by the structure govern which users are allowed to create new users, set individual settings, remove users, or request new values for certain settings. Certain changes, such as creation of new users or updates of setting values should be acceptable via batch input, MS-Excel input preferred. Request/Authorization Queues Certain settings are not directly adjustable by certain users, but instead are open for request. When requests are made, authorizers must be made aware of the request (notification via email preferred), and must be able to view and authorize outstanding requests. Incoming requests should show the authorizer the requesting user, the target user, the target user's current setting values, and the requested setting values. Audit Reporting Various audit information must be available. Internal audit information should include reporting regarding which internal users are permitted to perform certain administrative functions. Reporting may also be required regarding administrative abilities as they existed at certain times in the past. Individual user audits must include a history of setting values, along with when those changes were made, and by which user. The state of a user at any given time should be re-creatable using this information. [insert timeframe of history reportingÑshould be user-based, not time based.] Data replication User data should be capable of being quickly replicated to backup or parallel systems as it is entered on a transaction-level. In addition to transaction-level updates, full data dumps should also be available, and schedulable on a regular basis. Data Accessibility Programmatic Access Data should be accessible by FTID applications programmatically using established protocols such as LDAP (strongly preferred) or through various API's. These access methods must be secure, and should be capable of handling a high volume of calls (200+ per second) with low latency. Requests should be capable of functions similar or equal to those listed above, including (where permitted by data structure rules): ¥ Individual user requests ¥ User searches ¥ Adjusting user settings ¥ Requesting user settings Support for mainframe applications is not necessary, but a considerable plus. Integration into provisioning options Certain service settings will be variable according to data managed elsewhere by IDC. This information needs to be automatically integrated into the data structure, where applicable. Integration should be implemented again via a standard protocol or supplied API's. Example: SuperPrice has a multiple-choice setting called 'Format'. The list of viable formats is located in a separate database maintained elsewhere by FTID. As that list of formats changes, those changes must be integrated into the multiple-choice list shown for 'Format' while modifying or requesting values for this setting.