Hyperion Security Architecture and Flow of Internal product communication

Impacts and Recommendation

Impact of lots of groups and users would be late login in Workspace as determining which user has got access to which artefact and application will take a lot of time as the Ldap will have to go through a lot of users and groups.

Impact of lot of custom roles to provision the application would take time to load because during the opening of the application two activities take place

HFM database is loaded with current user’s active security session information Active users provisioning information is checked against HFM artefacts to load

Impact of lot of Security classes then the loading of Specific Object like journal or form would take more than normal time as the return of the request has to go through join of two huge tables one of which is a huge list of active security

class.

Security Model within Hyperion Product suite

Program Access: Only users who are linked to Hyperion's Shared Services AND have the proper provisioned rights can open a program. (I.e. HFM, Reports, Workspace, FDM, etc, etc, etc.)Provisioning: There are different types of rights per program that a user can have. Provisioning is the act of assigning these rights. (I.e. HFM has multiple rights such as Application Administrator, Default, Provisioning Manager, etc.)Data / Object Access: Even if you have the right to enter the program, there is generally another layer of security which controls what you can do. For instance, inside of HFM, you can configure security for objects such as Data Forms and Data Grids. Furthermore, you can limit the user's ability to change or view data for specific entities, accounts, as well as other dimensions.Security Classes: The security classes that you assign in the metadata are used during the act of assigning the Data / Object access controls. Users (and Groups) and assigned View Only, All (Read/Write), or none access to HFM Security Classes.

Comparison between Application layer security and HSS held securityHFM .sec file :-- Which Groups / Users are provisioned for this specific App- Which Security Classes exist for this App- What roles for this app do users / groups have.- What security class access level does users / groups have in this App

Shared Services:-- Management of Native Groups and Users (Add/Delete/Modify) for the entire environment. (not App based or even HFM based)- Membership management for Native Groups / Users. Linking groups to other groups and/or users- Provisioning roles for users/groups to an App (Same as what can be done in the Security File)- Creating Security Classes (like in Security File)- Assigning Class access between classes and users and/or groups (like you can do in Security File)- Managing roles for items OTHER THAN HFM (i.e. Workspace/Reports, etc.)

Some Common terminology

Authentication:  This is the process of verifying a users security credentials.  In essence it is the verification of the username and password against the security provider’s records.

Authorization/Provisioning:  This is the process which occurs after authentication.  In this process the users are granted access based on 'roles' or 'rights' to the product(s) in question.

External Provider:  This is a common security provider 'outside' the Hyperion EPM suite. It could be an LDAP, OID, an NTLM and/or a MSAD.  Regardless of version, this represents a corporate security source.

Internal Provider:  This is a security model which leverages 'Native' security where the users and/or groups are stored 'within' the Hyperion EPM suite themselves.  In System 9 all of the Role information is stored in an OpenLDAP store which is part of the Hyperion EPM suite

CSS.xml (shared services configuration information): Shared services web application server uses this file to collect information about native/external providers such as MSAD configuration details