The Programs (which include both the software and documentation) contain proprietary information; they are provided
under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and
other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except
to the extent required to obtain interoperability with other independently created software or as specified by law, is
prohibited.
The information contained in this document is subject to change without notice. If you find any problems in the
documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be
expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the
United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to
U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the
applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication,
disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject
to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional
rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500
Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous
applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures
to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any
damages caused by such use of the Programs.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their
respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is
not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with
the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly
between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b)
fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty
obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you
may incur from dealing with any third party.
Contents
Chapter 1. About Hyperion Security ..................................................... 11
Hyperion application security comprises two distinct and complementary layers that control
user access and permissions:
●“User Authentication” on page 11
●“Provisioning (Role-Based Authorization)” on page 14
About Hyperion Security
User Authentication
User authentication enables single sign-on functionality across Hyperion products by validating
the login information of each user to determine authenticated users. User authentication, along
with product-specific authorization, grants the user access to Hyperion products. Authorization
is granted through provisioning.
Single sign-on (SSO) is a session and user authentication process that permits a Hyperion
product user to enter credentials only once at the beginning of a session to access multiple
Hyperion products. SSO, which is requested at session initiation, eliminates the need to log in
separately to each Hyperion product to which the user has access.
Authentication Components
These components are used to support SSO:
●“Security API” on page 12
●“Native Directory” on page 12
●“User Directories” on page 12
Security Components
11
Security API
The Security Application Programming Interface (Security API) is the main interface to validate
users and interpret user access to Hyperion products. It is a Java API that enables Hyperion
products to authenticate users against user directories configured in Oracle's Hyperion® Shared
Services. It also allows integration with a security agents such as Netegrity SiteMinder, and
retrieval of users and groups based on names and identities. Each Hyperion application
implements the Security API to support user authentication.
Native Directory
Native Directory (OpenLDAP), an open source Lightweight Directory Access Protocol (LDAP)enabled user directory, is bundled and configured with Shared Services.
Native Directory functions:
●Used to maintain and manage the default Shared Services user accounts required by
Hyperion products
●Is the central storage for all Hyperion provisioning information because it stores the
relationships between users, groups, and roles.
Native Directory is accessed and managed using the User Management Console. Refer
toChapter 7, “Managing Native Directory” for more information on provisioning users.
User Directories
User directories refer to any corporate user and identity management system compatible with
Shared Services. Hyperion products are supported on a large number of user directories. These
include LDAP-enabled user directories, such as Sun Java System Directory Server (formerly
SunONE Directory Server) and Microsoft Active Directory, Windows NT LAN Manager
(NTLM); SAP Provider; and custom-built user directories that support LDAP version 3.
In addition to Native Directory, which is automatically configured for your environment, one
or more user directories can be configured as the user information provider for Hyperion
products.
User directories used with Hyperion products must contain an account for each user who
accesses Hyperion products. These users may be assigned to groups to facilitate provisioning.
User Authentication Scenarios
●“Single Sign-on Directly to Hyperion Products” on page 12
●“Single Sign-on from External Systems” on page 13
Single Sign-on Directly to Hyperion Products
About Hyperion Security
12
Direct authentication connects Hyperion products to available user directories to verify the user
name and password (credentials) entered on the Login screen.
1. Using a browser, users access the Hyperion product login screen. They enter user names
and passwords.
The Security API implemented on the Hyperion product queries the configured user
directories (including Native Directory) to verify user credentials. A search order is used to
establish the search sequence. On finding a matching user account in a user directory, the
search is terminated and the user's information is returned to the Hyperion product.
Access to Hyperion product is denied if a user account is not found in any of the user
directories.
2. Using the retrieved user information, the Hyperion product queries Shared Services to
obtain provisioning details for the user. Provisioning details are stored in Native Directory.
On receiving provisioning information from Shared Services, the appropriate Hyperion product
is made available to the user. At this point, SSO is enabled for all Hyperion products for which
that user is provisioned. Access permissions within Hyperion products are determined by the
provisioning information.
Single Sign-on from External Systems
Hyperion products can be configured to accept pre-authenticated users from external sources,
such as Netegrity SiteMinder and SAP Enterprise Portal, to enable SSO. In this scenario,
Hyperion products use the user information provided by a trusted external source to determine
access permissions of users.
SSO with SAP is supported by accepting an SAP logon ticket. In this scenario, users defined in
an SAP user directory can navigate between the SAP Portal and Hyperion products. If an SAP
provider is configured, users can also directly log on to Hyperion products using the user ID
and password stored in the SAP system. The SAP provider creates the SAP logon ticket to enable
SSO with SAP systems.
User Authentication
13
1. Using a browser, users access the login screen of a web identity management solution (for
example, SiteMinder) or SAP Enterprise Portal. They enter user names and passwords,
which are validated against configured user directories to verify user authenticity. Hyperion
products are also configured to work with these user directories.
When users navigate to a Hyperion product, information about the authenticated user is
passed to Hyperion product, which accepts the information as valid.
If the user logged on to SAP Portal, an SAP logon ticket is passed to Hyperion product. The
Security API implemented on Hyperion product decrypts the SAP logon ticket using a
specified SAP certificate.
If the user logged on to a web identity management solution, a custom
header is passed to Hyperion product.
2. To verify user credentials, Hyperion product tries to locate the user in one of the user
directories based on the search order. If a matching user account is found, user information
is returned to Hyperion product.
3. Using the retrieved user information, Hyperion product queries Shared Services to obtain
provisioning details for the user.
On receiving user provisioning information from Shared Services, the Hyperion product is
made available to the user. SSO is then enabled for all Hyperion products for which that
user is provisioned.
Provisioning (Role-Based Authorization)
Hyperion application security determines user access to products using the concept of roles. A
role is a set of permissions that determines user access to product functions.
Each Hyperion product provides several default roles tailored to suit various business needs.
Predefined roles from each Hyperion application registered with Shared Services are available
from User Management Console. These roles are used for provisioning. You may also create
additional roles that aggregate the default roles to suit specific requirements. The process of
HYPLOGIN HTTP
About Hyperion Security
14
granting users and groups specific access permissions to Hyperion resources is called
provisioning.
Native Directory and configured user directories are sources for user and group information for
the provisioning (authorization) process. You can browse and provision users and groups from
all configured user directories from User Management Console. Provisioning data is stored in
Native Directory. You can also use application-specific aggregated roles created in Native
Directory in the provisioning process.
This illustration depicts a broad overview of the authorization process:
1. After a user is authenticated, Hyperion product queries the user directories to determine
the user's groups.
2. Hyperion product uses the group and user information to retrieve the user's provisioning
data from Shared Services. The product uses this data to determine resources that a user can
access.
Product-specific provisioning tasks, such as setting product-specific access control, are
completed from each product. This data is combined with provisioning data to determine
the product access for users.
Role-based provisioning of Hyperion products uses these concepts.
Roles
A role is a construct (similar to access control list) that defines the access permissions granted
to users and groups to perform functions on Hyperion resources. It is a combination of resource
or resource types (what users can access; for example, a report) and actions that users can perform
on the resource (for example, view and edit).
Access to Hyperion application resources is restricted; users can access them only after a role
that provides access is assigned to the user or to the group to which the user belongs. Access
restrictions based on roles enable administrators to control and manage application access.
Provisioning (Role-Based Authorization)
15
Global Roles
Global roles are Shared Services roles that enable users to perform certain tasks within the User
Management Console. See Appendix B, “Shared Services Roles and Permitted Tasks” for a
complete list of Shared Services global roles.
Administrator
The Administrator role provides control over all products that integrate with Shared Services.
It enables more control over security than any other Hyperion product roles and should therefore
be assigned sparingly. Administrators can perform all administrative tasks in User Management
Console and can provision themselves.
This role grants broad access to all applications registered with Shared Services. The
Administrator role is, by default, assigned to the admin Native Directory user, which is the only
user available after you deploy Shared Services. This user account is initially used to create
accounts for other administrators. For example, the Shared Services Administrator assigns other
administrative users either the Directory Manager or Provisioning Manager role (a productspecific role assigned for individual applications). In turn, these users manage general user access
to applications.
Directory Manager
Users who are assigned the Directory Manager role can create and manage users and groups
within Native Directory.
Do not assign to Directory Managers the Provisioning Manager role because combining these
roles allows Directory Managers to provision themselves. If a user is assigned the Provisioning
Manager role for an Oracle's Hyperion® Essbase® – System 9 application as well as the Directory
Manager role, this user can create a new user, assign the user any role within the Essbase
application, and log in as the new user, thereby granting personal access to the Essbase
application.
The recommended practice is to grant one user the Directory Manager role and another user
the Provisioning Manager role.
Project Manager
Users who are assigned the Project Manager role can create and manage projects within Shared
Services.
LCM Manager
Users who are assigned the LCM Manager role can execute the Artifact Life Cycle Management
Utility to promote artifacts and data across product environments and operating systems.
About Hyperion Security
16
Predefined Roles
Predefined roles are built-in roles in Hyperion products. You cannot delete these roles from the
product. Predefined roles are registered with Shared Services during the application registration
process.
Aggregated Roles
Aggregated roles are custom roles that aggregate multiple product roles within a Hyperion
product. An aggregated role consists of multiple roles, including other aggregated roles. For
example, a Shared Services Administrator or Provisioning Manager can create a role for Planning
that combines the Planner and View User roles into an aggregated role. Aggregating roles can
simplify the administration of products that have a large number of granular roles.
You cannot create an aggregated role that spans products, and you cannot include global Shared
Services roles in aggregated roles. Aggregated roles are also known as custom roles.
Users
User directories store information about the users who can access Hyperion products. Both the
authentication and the authorization processes utilize user information. You can only create
and manage Native Directory users from User Management Console.
Users from all configured user directories are visible from User Management Console. These
users can be individually provisioned to grant access rights on the Hyperion products registered
with Shared Services. Hyperion does not recommend the provisioning of individual users.
Groups
Groups are containers for users or other groups. You can create and manage Native Directory
groups from User Management Console. Groups from all configured user directories are
displayed in User Management Console. You can provision these groups to grant permissions
for Hyperion products registered with Shared Services.
Provisioning (Role-Based Authorization)
17
About Hyperion Security
18
Setting Up Authentication
2
In This Chapter
Setting Up Direct Authentication to Hyperion Products ........................................................................19
Setting Up SSO with SAP Enterprise Portal......................................................................................21
Setting Up SSO from SiteMinder .................................................................................................25
Using NTLM to Support SSO ......................................................................................................28
Setting Up Direct Authentication to Hyperion Products
The security environment of Hyperion products comprises two complementary layers:
authentication and authorization.
Setting up Hyperion security to authenticate users directly involves several broad procedures.
See details in later sections.
●“Creating Users on the User Directory” on page 19
●“Creating Groups” on page 20
●“Migrating Users and Groups to Shared Services Security” on page 20
●“Installing and Deploying Shared Services” on page 20
●“Identifying User Directories to Shared Services” on page 20
Creating Users on the User Directory
The security environment of Hyperion products requires that user credentials be checked against
a user directory as a part of the authentication process. This requirement mandates that each
Hyperion application user have an account on the user directory. A unique user identifier
(typically the user name) defined on the user directory is the foundation on which Hyperion
application security is built.
In most deployment scenarios, existing user directories (with user accounts) are used to support
user authentication. For information on creating user accounts, see vendor documentation. See
“Creating Users” on page 81 for information on creating Native Directory users.
Setting Up Direct Authentication to Hyperion Products
19
Creating Groups
User accounts on user directories can be granted membership to groups based on common
characteristics such as the user function and geographical location. For example, users can be
categorized into groups such as Staff, Managers, Sales, and Western_Sales based on their function
within the organization. A user can belong to one or more groups on the user directory, which
is an important consideration in facilitating the provisioning process.
The procedures to create groups and assign group membership vary depending on the user
directory being used. For information on creating groups and assigning group membership, see
vendor documentation. See “Managing Native Directory Groups” on page 84 for information
on creating Native Directory groups.
Migrating Users and Groups to Shared Services Security
If you are upgrading Hyperion products from a release that did not support provisioning, you
must migrate users and groups from the products to Shared Services. You can migrate users who
were authenticated through native product security or through an external directory in that
release. Each product has a migration tool that enables you to migrate user, group, and role
information from Hyperion products to Shared Services. For migration information, see the
appropriate product appendix at the end of this guide.
After migrating users, you can provision users or groups as needed. See Chapter 8, “Managing
Provisioning” for details.
Installing and Deploying Shared Services
See Hyperion Shared Services Installation Guide for information about installing Shared Services
and deploying it to an appropriate application server.
Identifying User Directories to Shared Services
The Shared Services installation and deployment process sets up and configures Native Directory
as the default user directory for Hyperion products. Each additional user directory that you use
to support user authentication and SSO must be configured separately using User Management
Console.
During the user directory configuration process, you assign the search order for each user
directory. This order determines the sequence in which the authentication process searches
within configured user directories to locate the user account that matches the user login
credentials. By default, Hyperion application security is configured to terminate the search
process when a matching user account is found. If you are using multiple user directories,
Hyperion recommends that user accounts be normalized across user directories.
Setting Up Authentication
20
Information on configuring user directories:
●“Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User
Directories” on page 40
●“Configuring an SAP Provider” on page 46
●“Configuring an NTLM User Directory” on page 49
Setting Up SSO with SAP Enterprise Portal
Hyperion products handle SSO to SAP Enterprise Portal by issuing an SAP logon ticket. This
action enables users who log in to Hyperion products to navigate seamlessly to SAP applications.
The illustrated concept:
1. When a user logs in to Hyperion products, the Security API implemented on the product
authenticates the user against configured user directories, including Native Directory.
Hyperion pr oduct iss ues a Hype rion logon token, w hich enable s SSO to Hy perion pro ducts.
The Hyperion logon token contains an SAP logon ticket.
Note:
For SSO with SAP to work, you must configure SAP as valid provider on Shared Services.
2. When the user subsequently navigates to the SAP system or uses an SAP data source, the
SAP logon ticket contained in the Hyperion token is passed to SAP to enable SSO. At this
point, the SAP system assumes the responsibility to validate the credentials in the SAP logon
ticket.
Hyperion products handle SSO from SAP Enterprise Portal by accepting an SAP logon ticket.
This action enables users who log in to SAP Enterprise Portal to navigate seamlessly between
SAP and Hyperion products. The illustrated concept:
Setting Up SSO with SAP Enterprise Portal
21
1. When a user logs in to SAP Enterprise Portal, SAP authenticates the user against the SAP
provider and issues an SAP logon ticket. SSO to SAP is enabled at this time.
2. The user navigates to a Hyperion product. The SAP logon ticket is passed to the Hyperion
product, which decrypts the SAP logon ticket using a SAP certificate stored on the Shared
Services server machine to retrieve the user name.
3. Accepting the user name, retrieved from the SAP ticket, as a valid, the Hyperion product
queries user directories to determine the user's groups. The SAP provider must be configured
as a user directory in Shared Services for this process to work.
4. Using the group information, Hyperion product gets the provisioning information for the
user from Shared Services.
Assumptions in both scenarios:
●If using a non-SAP corporate directory, the corporate user directory used by SAP Enterprise
Portal is supported by Shared Services. See Hyperion Installation Start Here for a list of
supported user directories.
●Users accounts and groups are already defined on the corporate user directory.
●The corporate user directories are configured to work with Shared Services.
●Users and groups are provisioned to access Hyperion products.
Setting Up Authentication
22
Nested SAP Groups
After configuring an SAP user directory, available SAP users and groups are displayed in User
Management Console. Shared Services considers the SAP roles to be the equivalents of groups
created by any corporate directory server. Each role from the SAP user directory is displayed as
a distinct group in User Management Console. Shared Services, however, does not retrieve the
relationships that exist between simple and composite roles within the SAP user directory. If
needed, nested groups can be created in Native Directory to mimic the relationship that existed
between the simple and composite roles in the SAP user directory.
Inheritance Policy for Nested Groups
If you use nested groups from Native Directory to mimic nested SAP groups for provisioning,
the component groups inherit the roles assigned to the nested group. The illustrated concept:
In addition to the roles assigned directly to it, each component role (for example, Group2)
inherits all the roles assigned to the nested group (Role8 and Role9 in the illustration). For
example, the role assi gnment of Grou p1 in the ill ustratio n is Role1, Role 8, and Role9. T he nested
group does not inherit the groups assigned to component groups.
Deployment Locations
Deployment location conventions:
●<
Hyperion_Home
> denotes the root directory where Hyperion products are installed. The
location of this directory is specified during the installation process. For example:
C:\Hyperion (Windows)
/vol1/Hyperion (UNIX)
●<
HSS_Home
C:\Hyperion\deployments\<
/vol1/Hyperion/deployments/<
> denotes the Shared Services root directory. For example:
App_Server_Name
App_Server_Name
>\SharedServices9 (Windows)
>/SharedServices9 (UNIX)
Prerequisites
●All SAP systems within the SAP landscape must be set up for single sign-on with the SAP
login ticket. User names must be normalized across the SAP landscape so that a user name
in one SAP system refers to the same user across all SAP systems. See the SAP documentation
for more information.
●Copy or download the SAP JCo binaries (.dll files for Windows and shared libraries for
UNIX) into
<Hyperion_Home>
/common/SAP/bin directory. For example:
/vol1/Hyperion/common/SAP/bin(UNIX)
C:\Hyperion\common\SAP\bin (Windows).
These binaries are available in your SAP distribution. Registered SAP users may also
download them from the SAP Web site
https://service.sap.com/connectors.
Setting Up SSO with SAP Enterprise Portal
23
●Copy or download the SAP JCo archives (.jar files) into
SAP/lib
directory. For example:
<Hyperion_Home>
/vol1/Hyperion/common/SAP/lib (UNIX)
C:\Hyperion\common\SAP\lib (Windows)
These binaries are available in your SAP distribution. Registered SAP users may also
download them from the SAP Web site
https://service.sap.com/connectors.
/common/
●Copy or download the following SAP libraries into
lib
directory. For example,
<Hyperion_Home>
/common/SAP/
/vol1/Hyperion/common/SAP/lib (UNIX)
C:\Hyperion\common\SAP\lib (Windows)
These libraries are required to verify the SAP SSO logon ticket provided to Hyperion
products. You can extract these libraries from the file system of any SAP J2EE Engine 6.30
or later release. Or extract them from Enterprise Portal EP60 SP2 or later by searching
through the SDA files containing libraries. This step is required only if Hyperion products
are plugged into SAP Enterprise Portal.
❍com.sap.security.core.jar
❍com.sap.security.api.jar
❍sapjco.jar
❍sap.logging.jar
❍iaik_jce.jar
❍iaik_jce_export.jar (if using the export version of the IAIK-JCE libraries)
●Expand the contents of each of the SAP jar files by running the explodejar.bat
(Windows) or explodejar.sh (UNIX) file available in the
SAP/lib
directory.
<Hyperion_Home>
/common/
Setting Up Authentication
24
●Using User Management Console, configure the SAP provider for Shared Services. See
“Configuring an SAP Provider” on page 46 for detailed information.
●If you are providing SSO to Hyperion products from SAP Enterprise Portal, install the SAP
Digital Certificate (SAP X509 certificate) in a convenient location. Hyperion recommends
that this certificate be installed in the following directory where the
●Using User Management Console, provision SAP users and groups to provide them
CSS.xml file is stored:
appropriate access rights to Hyperion products. See Chapter 8, “Managing Provisioning”
for detailed information.
Setting Up SSO from SiteMinder
Hyperion products can be integrated with Web access management solutions such as Netegrity
SiteMinder to provide SSO to Hyperion products. Where SSO from SiteMinder is accepted,
Hyperion products trust the authentication information sent by SiteMinder regarding the
protected resources on the user directory. The illustrated concept:
1. When a user logs in to SiteMinder to access Hyperion products, SiteMinder presents a login
screen. SiteMinder forwards the user credentials to the SiteMinder Policy Server, which
authenticates users against configured user directories.
2. If the user is authenticated, the SiteMinder Policy Server grants access to Hyperion products
and passes a SiteMinder token that has
HYPLOGIN is configured to SM_USERLOGINNAME parameter in SiteMinder.
Note:
In SiteMinder Version 6, configure HYPLOGIN to use SMUSER parameter. HYPLOGIN is a
header that you must create to support SiteMinder integration with Hyperion products. See
SiteMinder documentation for information on configuring
carry the user name of the authenticated user.
3. The Security API implemented on the Hyperion product parses the
and validates the user against the user directories configured on Shared Services.
4. Hyperion product checks Shared Services for the user's provisioning information. Based on
the provisioning information, the Hyperion product provides access to the user.
To enable SSO, SiteMinder and Shared Services must be configured to use the same set of user
directories. Also, the user directories configured in Shared Services must be set up to support
security agent for single sign on. See “Setting Global Parameters” on page 57 for details.
The SiteMinder–enabled SSO, general overview:
HYPLOGIN HTTP header appended to it.
HYPLOGIN HTTP header to
HYPLOGIN HTTP header
Setting Up SSO from SiteMinder
25
The following SiteMinder security agents are tested and supported for SSO with Hyperion
products:
●SiteMinder Policy Server 5.5 SP 2
●SiteMinder Web Agent 5.5 SP 2
Note:
The corporate user directories configured with Shared Services must be trusted when SSO from
SiteMinder is enabled. This is because Shared Services does not store a password in the token
when a security agent is used.
Special Considerations
SiteMinder is a Web only solution. Desktop applications and their addins (for example,
Microsoft Excel and Report Designer) cannot use authentication through SiteMinder.
Hyperion products are supported only on NTLM and LDAP-enabled user directories (including
MSAD).
Setting Up Authentication
26
Configuring the SiteMinder Policy Server
A SiteMinder administrator must configure the policy server to enable SSO to Hyperion
products.
The configuration process:
●Setting up protection for the Web resources of Hyperion products.
●Configuring a response that adds a custom HTTP header to make the user login name
available to Hyperion applications. The header must include the parameter
HYPLOGIN and
must contain the login name of the authenticated user.
See the “Responses and Response Groups” topic in the Netegrity Policy Design Guide for detailed
information. For example, if you use
attribute in the configuration file, the
cn from an LDAP–enabled user directory as the login name
HYPLOGIN parameter should carry the value of the cn
attribute, which is the login name of the authenticated user. SiteMinder administrators can also
configure the header to
SM_USERLOGINNAME (SMUSER for SiteMinder version 6), the user name
specified by the user during logon.
Configuring the SiteMinder Web Agent
The Web agent is installed on a Web server that intercepts requests for Hyperion application
Web resources, such as JSPs, ASPs, and HTML files on the application server. If these Web
resources are protected, the Web agent issues a challenge to unauthenticated users. When a user
is authenticated, the policy server adds
authenticated user. Thereafter, the HTTP request is passed on to the Web resources of the
Hyperion application, and the login name is extracted from headers.
HYPLOGIN, which carries the login name of the
SiteMinder supports SSO across Hyperion products running on heterogeneous Web server
platforms. If Hyperion products use different Web servers, you must ensure that the SiteMinder
cookie can be passed among Web servers within the same domain. You do this by specifying the
appropriate Hyperion application domain as the value of the
WebAgent.conf file of each Web server.
Cookiedomain property in the
See the “Configuring Web Agents” chapter in the Netegrity SiteMinder Agent Guide.
Note:
Because Shared Services uses basic authentication to protect its content, the Web server that
intercepts requests to Shared Services should enable basic authentication to support SSO with
SiteMinder.
Enabling SiteMinder Authentication in Shared Services
Integration with SiteMinder requires that you enable SiteMinder Authentication in Shared
Services. This can be done from User Management Console or by editing the
1 In Shared Services, configure the user directories that SiteMinder use to authenticate users. See the following
topics:
●“Configuring Oracle Internet Directory, MSAD, and Other LDAP-Enabled User
Directories” on page 40
●“Configuring an NTLM User Directory” on page 49
2 Select the Support for Security Agent for Single Sign-oncheck box to specify that the user directories are
used to support SSO from security agents such as SiteMinder. See “Setting Global Parameters” on page
57.
Other Procedures
You must perform these tasks, if not already completed:
●Using User Management Console, configure the corporate directories used by SiteMinder.
See Chapter 4, “Configuring User Directories.”
●Using User Management Console, provision the users and groups to grant appropriate
access to Hyperion products. See Chapter 8, “Managing Provisioning.”
Using NTLM to Support SSO
Shared Services allows you to configure Windows NT LAN Manager (NTLM) as a user directory
to support SSO. Refer to “Configuring an NTLM User Directory” on page 49 for information
on configuring the NTLM user directory.
Under these conditions, you must perform prerequisite steps to support SSO using NTLM:
●NTLM user directory is to be used to authenticate and provision users where Shared Services
and Hyperion products are running in a UNIX environment. In this scenario, Hyperion
Remote Authentication Module must be deployed on the Windows domain that contains
the user accounts.
●Shared Services and Hyperion products are running in a Windows environment, but users
are in Windows NTLM domains that are not trusted on the domain where the Shared
Services host machine is installed. The prerequisite for this scenario is that you deploy
Hyperion Remote Authentication Module on each domain that is not trusted by the domain
where Shared Services host machine is installed.
Do not implement Hyperion Remote Authentication Module if all users belong to the NTLM
domain where the Shared Services host machine is installed or if a trust relationship is established
between the domain where the Shared Services host machine is installed and the NTLM domains
to which users belong.
Setting Up Authentication
28
NTLM with UNIX Application Environments
The following illustration depicts how the Hyperion Remote Authentication Module enables
communication between NTLM and Shared Services running in a UNIX environment.
The Shared Services configuration file (CSS.xml) resides on the application server, as do the
Hyperion application binaries. For NTLM connectivity, you also need NTLM support library
css-9_3_0.dll) on the machine that hosts Hyperion Remote Authentication Module in
file (
the NTLM domain.
The NTLM Primary Domain Controller and the Hyperion Remote Authentication Module can
be on a Windows 2000 or Windows 2003 server. Hyperion does not recommend, however, that
you combine the Hyperion Remote Authentication Module with the NTLM Primary Domain
Controller on the same server. The Hyperion Remote Authentication Module host machine
needs to be in the same domain as the NTLM Primary Domain Controller.
Support for Multiple NTLM Domains
Hyperion Remote Authentication Module enables a Hyperion product to authenticate users
belonging to other NTLM domains that are not trusted by the domain on which Shared Services
is installed.
The following illustration depicts how users spread across multiple NTLM domains can be given
access to Hyperion products deployed in a Windows environment:
Using NTLM to Support SSO
29
Without the Hyperion Remote Authentication Module, the only way to use multiple NTLM
domains for Hyperion products is to establish trust relationships between the Shared Services
host machine's domain and the NTLM domains where user accounts are available.
Setting Up Authentication
30
Loading...
+ 176 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.