Date Author Version Change Reference

Transcription

1 DESIGN AACG ETL Adapter for Hyperion V1.0 Author: Sundeep Nayak Creation Date Last Updated: File URL: Draft / Version: 2.0 Status: Beta Document Control Change Record Date Author Version Change Reference Su Sundeep Nayak 1.0 First draft Sundeep Nayak and Yasir Shah 2.0 Beta

2 Table of Contents 1. Introduction... 2 Scope for this document Technical Overview of Hyperion ETL Adapter... 2 a. Functional Security... 3 Java APIS to extract data... 4 b. Data Security... 5 Security Classes... 5 Global conditions for Hyperion Datasource(To be finalized in V1.01) Mapping into the AACG Repository (Extract Target) Introduction Scope for this document Access Control Governor(ACG) V8.5 interfaces with ETL adapters that can extract security access models from Oracle Ebiz, and Peoplesoft applications to perform Seggregation of Duties(SOD) voilation analysis of ACG defined policies. The scope of this project is to prove the technicial viability of an ETL adapter that could do a similar extract from a Hyperion Security Access model. The ETL extract required for the analysis should be capable of performing the following 1. An initial full-load pull of the Hyperion Users, Groups and Roles data 2. Subsequent incremental-load pulls of changed data (new inserts and update deltas) since the initial pull 2. Technical Overview of Hyperion ETL Adapter The goal of the Hyperion ETL adapter is to be able to both the functional data of the Hyperion access model (Users, Groups and Roles) using the

3 hyperion CSS Java APIs and the security class related data security using yet to be determined apis (or using direct SQL for the time being). Hyperion Functional Security Data (LDAP store) in HFM Hyperion Data Security (Security Classes) in HFM HSS CSS APIS HFM APIs Hyperion Adapter Java Wrapper Full Load Hyperion ODI Staging tables Incremental Load using ODI Scenarios AACG Adapter repository AACG DB Instance a. Functional Security The Hyperion shared services (HSS) enables the below CSS APIs to get the functional data

4 Java APIS to extract data Returns Method CSSUserIF authenticate(java.util.map context) - authenticates the user with a token CSSUserIF[] getusers(java.util.map context, java.lang.string username) Gets the user specified by username. CSSGroupIF[] getgroups(java.util.map context, java.lang.string groupname) Get a group based on the name or wildcaredx. CSSRoleIF[] getroles(java.util.map context, CSSPrincipalIF principal, java.lang.string rolename, java.lang.string typeofaccess, java.lang.string applicationid) Gets the roles associated with this application. The advantages of using the above CSS Java APIS (available as JARs) as opposed to going against the LDAP Store using JNDI/ODI directly are: 1. Abstraction: The Apis provide the level of abstraction to the GRC Hyperion Adapter from the LDAP storage schema. Any future schema changes will NOT affect GRC Adapter code 2. Implementation Independence: The LDAP store will support not just Oracle Internet Database but also other widely used stores like Active Directory and iplanet and there is a slight variance in data audit mechancisms.(for eg. some of them use Change Log). The same OPSS APIs will support incremental data pull irrespective of the underlying LDAP store implementation. 3. Performance: LDAP structure is heirarchial and slow. The query that APIs use been optimized for performance

5 b. Data Security Security Classes Users and groups are assigned to Security Classes are used in Hyperion to allow access to data in an HFM functionality. The Security class maintains one of the following access levels: 1. None 2. Metadata 3. Read 4. Promote 5. All In Phase I we want to focus on having Security Classes pulled into AACG as attributes/dimensions. During conflict analysis we would be able to choose which Security Classes to include /exclude. We would need the following data points to examine Hyperion Security Classes: 1. Security Class and its attributes 2. Users and Groups associated with Security Class 3. The link between a Security Class and a Hyperion Meta-data (eg. Account, Entity, Scenario dimensions.) These data points need to be loaded in AACG attribute tables for it to monitor the list of Security Classes. AACG is only able to handle a value and description; this leaves the access level unaccounted for. The access level will need to be recorded as part of the description field in the attribute field. Due to these restrictions, the Security Class name will be recorded and the access level will be recorded as the description field. Then users and groups as well as the Hyperion objects will be linked up to the Security Class attribute. Current API Support The only APIs that allow access to Security Classes are through COM Objects. The following prerequisites need to be met before developing using the HFM COM Objects:

6 You must install the Financial Management Windows client on your computer. You must either install the Financial Management application server files on your computer or you must have read access to a file system on which the application server files are installed. Access to the application server files is required so that your projects can reference the object model s type libraries. The main COM object to use is HsvSecurityAccess for accessing Security Classes. The following are the most relevant methods available from this object to deal with Security Classes: AddSecurityClass: Adds a security class to a Classic application. DeleteSecurityClass: Deletes a security class from a Classic application. EnumSecurityClasses: Returns arrays containing an application s security class IDs and names. The arrays have a one-to-one correspondence. EnumSecurityClassRightsForPrincipal: Returns arrays representing a user's access and alerting rights to security classes. The arrays have a one-to-one correspondence. EnumUserClassAccess: Returns the access and alerting rights that one or more users have for the specified security classes. GetApplicationAdministratorAccessForAllUsers2: Indicates which of an application s users are assigned to the Application Administrator role. This method returns arrays containing the usernames and security identifiers of the application s users and an array of flags indicating whether the users are assigned to the Application Administrator role. The arrays have a one-to-one correspondence. GetSecurityClassAccessForAllUsers2: Returns the access rights to a security class for all of an application s users. The method returns access rights and user information in arrays that have a one-to-one correspondence. GetSecurityClassID: Returns the ID of a security class, given the security class s name. GetSecurityClassLabel: Returns the name of a security class, given a security class ID. GetUserAccessForAllSecurityClasses2: Returns the level of access rights that a user has for each security class in an application. The

7 method returns access rights and security class information in arrays that have a one-to-one correspondence GetUserName2: Returns a username, given a security identifier. GetUserNameFromSID: Returns the username of a user, given the user s security identifier (SID). GetUserSID: Returns the security identifier for a given user. SetManySecurityClassRightsForUser2: Sets a user s access and e- mail alerting rights for one or more security classes. Security and access right IDs are passed in arrays that have a one-to-one correspondence. SetSecurityClassLabel: Changes the name of a security class in a Classic application. SetSecurityClassRightsForManyUsers2: Sets one or more users access and alerting rights to a given security class. Users security identifiers, access right IDs, and alerting flags are passed in arrays that have a one-to-one correspondence. SetSecurityClassRightsForUser2: Sets a user s access and alerting rights for a security class. SetUserClassAccess: Sets security class access and alerting rights for one or more users Please note Security classes are assigned to Entity dimension members, and you can get an entity s security class with HsvEntities object and using the GetSecurityClassID method. GetSecurityClassID returns the ID number of an entity s security class. In other words, this method returns the ID of the security class that has been defined for an entity s SecurityClass attribute. Analyzing Table Structure Security Class tables reside in the HFM Schema. For each HFM application there are the 2 tables that hold Security Class name and access information are: HSV_<Application Prefix>_SECCLASSES HSV_<Application Prefix>_SECCACCESS Each HFM application will have its prefix that will be pre-pended on tables, in the case of security classes it is appended after HSV_. These tables will identify the Security Class and the users/groups who are assigned to it. So if

8 there are 3 HFM applications 6 tables will exist to grab the information from. Each object has a table. These tables have the ability to identify which security classes are assigned. Each object s table will have references to the SECCLASSES->ItemID value. The objects reside in the following tables. The columns that are linked are generally named "SecurityClass" or "SecurityClassID". For each HFM application it will have the following tables that store the hfm object and security class relationship information. <Application Prefix> notes that the applications prefix is added to the beginning of these table names. Metadata access restrictions for data: <Application Prefix>_ACCOUNT_ITEM <Application Prefix>_ENTITY_ITEM <Application Prefix>_ICP_ITEM <Application Prefix>_CUSTOM1_ITEM <Application Prefix>_CUSTOM2_ITEM <Application Prefix>_CUSTOM3_ITEM <Application Prefix>_CUSTOM4_ITEM <Application Prefix>_SCENARIO_ITEM Journals: <Application Prefix>_JL_<S>_<Y> (<S> = ScenarioID and <Y> = Year, there can be multiple tables) <Application Prefix>_JLTMP Reports/Folders/Grids/Forms <Application Prefix>_RPTS These tables will then link to the Security Class it is assigned, and from there we can retrieve those users/groups assigned to a security class. Each of the above tables need to be linked with the HSV_<Application Prefix>_SECCLASSES to understand which of the above objects have a particular class assigned to it.

9 Scripts To get a listing of all the security classes you can run a query that looks like this: select * from hfm.hsv_<application Prefix>_SECCLASSES order by itemid; The following will return the users and the class they are assigned to: select ac.itemid, ac.usersid, DECODE(ac.accessrights, 0, 'None', 1, 'Metadata', 2, 'Read', 3, 'Promote', 4, 'All') AS Access_Level, sc.label As Security_Class from hfm.hsv_<application Prefix>_SECCACCESS ac, hfm.hsv_<application Prefix>_SECCLASSES sc where ac.itemid = sc.itemid ORDER BY sc.label; The following are scripts to get the relationship between classes and HFM objects, they will lack the extra metadata that may need to be captured which will be different for each HFM object: 1. ACCOUNTS select ad.description, sc.label As Security_Class from hfm.<application PREFIX>_ACCOUNT_ITEM ob, hfm.<application Prefix>_account_desc ad where ob.securityclass = sc.itemid and ob.itemid= ad.itemid ORDER BY sc.label; 2. ENTITY hfm.<application PREFIX>_ENTITY_ITEM ob where ob.securityclassid = sc.itemid ORDER BY sc.label; 3. ICP

10 hfm.<application PREFIX>_ICP_ITEM ob where ob.securityclass = sc.itemid ORDER BY sc.label; 4. CUSTOM1 hfm.<application PREFIX>_CUSTOM1_ITEM ob where ob.securityclass = sc.itemid ORDER BY sc.label; 5. CUSTOM2 hfm.<application PREFIX>_CUSTOM2_ITEM ob where ob.securityclass = sc.itemid ORDER BY sc.label; 6. CUSTOM3 hfm.<application PREFIX>_CUSTOM3_ITEM ob where ob.securityclass = sc.itemid ORDER BY sc.label; 7. CUSTOM4 hfm.<application PREFIX>_CUSTOM4_ITEM ob where ob.securityclass = sc.itemid ORDER BY sc.label; 8. SCENARIO hfm.<application PREFIX>_SCENARIO_ITEM ob where ob.securityclass = sc.itemid ORDER BY sc.label; 9. JOURNAL (Note there will be multiple tables depending on scenario and year) hfm.<application Prefix>_jl_<S>_<Y> ob where ob.securityclass_id = sc.itemid ORDER BY sc.label; 10. JOURNAL hfm.<application PREFIX>_JLTMP ob where ob.securityclass_id = sc.itemid ORDER BY sc.label; 11. REPORTS

11 hfm.<application Prefix>_rpts ob where ob.securityclass = sc.itemid ORDER BY sc.label; Global conditions for Hyperion Datasource(To be finalized in V1.01) Mapping into the AACG Repository (Extract Target) Upon the etl extraction, the hyperion security components above get mapped into the following AACG database objects AACG Datasource db object will store the connection information for use by ODI (database and OID)

12 AACG Access Type db object will store the distinct security type objects like Hyperion Roles and Hyperion Groups and possibly Security Class with access levels AACG Access table will store the extracted (from Hyperion instance) access points of Access Type above AACG Access link will store the realationship between the access points above AACG Users will store the extracted Hyperion application user infromation AACG User access will store the mapping between users and access points AACG global user will be used to maintain the integrity of the Policies across pillars and different sources AACG user Mapping will map each datasource application user to the Global User