x

External authorization is only supported in conjunction with the Trusted or External option for Managed Reporting authentication. For more information about these options, see Configuring Managed Reporting for Trusted or External Authentication.

x

The Managed Reporting authorization model is the same regardless of whether you select internal, Managed Reporting administered DBMS, or externally administered authorization. When you use internal or Managed Reporting administered DBMS authorization, the rules associated with this model are enforced in the MR Administration interface. When you configure externally administered authorization, you must make sure that your external authorization data complies with the model yourself.

An overview of the authorization model is presented below. See also Creating Roles, Groups, and Users in the WebFOCUS Managed Reporting Administrator's Manual.

• Role. A user must have exactly one role. The role concept makes it easier for administrators to define and manage user authorizations by assigning standard sets of privileges to many users with one role assignment.
• Privileges. A role can have one or more MR privileges. Privileges control which user interface loads for users and what they can do. Users can also have one or more privileges assigned directly to them (outside of their roles). For example, you can assign a user having the Analytical User role the shared privilege without having to create a new custom role called Analytical User with Shared. The set of valid privileges (referred to as flags) is defined in Property Flags in the WebFOCUS Managed Reporting Administrator's Manual.

  The Realm Driver does not detect or correct conflicting privilege settings. When implementing externally administered authorization, be careful not to create a situation where there are conflicting privileges between a user role and his or her individual privilege assignment.

• Domains. Report domains are created and maintained with Developer Studio or with Internet Explorer using the Domain Builder applet. You can also create a domain by properly describing it in the external authorization directory, as described in Creating Domains With Externally Administered Authorization.
• Groups. A group makes it easier to assign reporting resources to users. You map one or more domains to a group and then assign this group to one or more users. Users can belong to more than one group and their domain access is the set of all domains linked to those groups to which they belong. It is possible for a user to have access to a single domain by more than one group. Managed Reporting ignores duplicate domains during retrieval.

  Optionally, each group can be linked with a single Dashboard Group View and a Dashboard Role Tree. Users with access to more than one group are able to select between the multiple Group Views and Role Trees where applicable.

x

When Managed Reporting is configured for external authorization, several important actions take place during sign-on that do not occur with the internal authorization scenario. Administrators need to understand this behavior to more effectively manage the installation and to aid with troubleshooting.

It is useful first to understand what happens when Managed Reporting is configured for internal authorization and you create a new user account with the Managed Reporting Administration interface. After entering the required information in the interface and clicking Save, Managed Reporting creates a storage folder (basedir/userhref) for the user reports, a reference file (basedir/userhref.htm) for metadata about the user reports and deferred receipt tickets, and writes an entry for the user into basedir/user.htm. The value of userhref is formed by taking the first eight characters of the User ID found in the set [a..z | 0..9].

If ReportCaster is installed and the user has ReportCaster privileges, Managed Reporting also calls the ReportCaster API to make an entry in the ReportCaster Repository for the user. A similar synchronization is performed for Groups. WebFOCUS needs these storage/reference structures in place before a user can access any Managed Reporting or ReportCaster features.

Another important concept to understand is how reporting domains are created in the internal authorization scenario. Only a user with Managed Reporting administration privileges can create, rename, or delete a domain. These operations are performed through Developer Studio, the Domain Builder applet, and the Change Management load utility. When a new domain is created in these tools, Managed Reporting creates a storage folder (basedir/domainhref) for report content, a reference file (basedir/domainhref.htm) for metadata about the domain, and writes an entry for the domain into basedir/mrrepos.htm. Domain information is not synchronized with ReportCaster.

When you configure Managed Reporting for external authorization, you follow these guidelines:

• Managed Reporting Administered DBMS Authorization. You should create your users, groups, roles, and domains with the tools provided in Managed Reporting. When you follow this recommendation, all of the required storage/reference structures described previously will be created properly.

  If you have reason to update the DBMS tables directly (this is not recommended), you need to read the information and recommendations related to externally administered authorization carefully. Otherwise, you can skip to Preparing Dashboard and ReportCaster.

• Externally Administered Authorization. In this scenario, you cannot use the Managed Reporting Administration interface to create or manage your users, groups, and roles because the driver does not write through to the external directory. Instead, you are managing this authorization data yourself with native, third-party, or custom tools designed for this purpose.

  If you create domains with the Managed Reporting tools provided, the basedir/mrrepos.htm file is updated, but domain references in the external directory (which are used to determine authorization) are not. Two ways to approach this synchronization issue are presented in Creating Domains With Externally Administered Authorization.

1. In an externally administered configuration, an administrator or program is adding/maintaining both user authorization and domain description information in the external directory. At this point, Managed Reporting does not know anything about this information.
2. Consider that a user jt1234 signs on to Managed Reporting for the first time. If trusted authentication is configured, a password check is not performed. If external authentication is configured, a call is made to the external directory (3) to validate the credentials.
3. Next, Managed Reporting checks the external directory for the user role and privileges to see if the user has the inactive flag, indicating that he or she is being denied logon rights to Managed Reporting. If not, the user is authenticated.
4. If the user has ReportCaster privileges and the SYNC_CASTER_ON_MRSIGNON setting of the authorization directory is set to true, Managed Reporting calls the ReportCaster API to create or update the user in the ReportCaster Repository.

   This call to the API is made in the user context specified by the IBIMR_RC_SVCUSER setting (select Configuration, Managed Reporting in the WebFOCUS Administration Console). The ID specified in this setting is admin by default. The ID used for this call must have ReportCaster administrator privileges, meaning that it must either be a user in BOTUPROF with ReportCaster administrator privileges, or it must be specified in the General, User Info, Administrator setting in the ReportCaster Server Configuration tool.

   Note: When creating users with the Managed Reporting Administration interface, the user context of the administrator user in the tool makes the call to the API and not the user specified in IBIMR_RC_SVCUSER.

5. Managed Reporting now checks for the report storage area of the user in the basedir. It is created automatically if not found.

   The storage folder of the user and reference file are always created in lowercase, regardless of the case the user entered in the login page or the value of the USERID.CASE setting in the console.

   Note: Special characters in the user ID are converted to a hexadecimal format when the storage folder of the user is created in the basedir. The set of special characters includes the space and any of the following characters: \ / : * ? " < > |

6. During logon, Managed Reporting will synchronize the external domain list with the basedir. This means that domains found in the external directory are created in the basedir if they do not exist. However, only those domains that the user logging on has access to are created during this process. It is a good idea when adding new domains to the external repository that you log on as a user with Managed Reporting administrator privileges so that all the domains will be created at once.

   For more information, see Creating Domains With Externally Administered Authorization.

Key points to remember are that the basedir/user.htm file is not maintained when external authorization is configured, and that you need to decide how to handle domain creation with externally administered authorization.

Also, it is generally possible to switch from internal to external authorization, provided that the user IDs match in each case. However, users who have logged on to a system configured for external authorization will no longer be able to log on if authorization is switched to internal. This is because even though the users have a storage area under basedir, they will have no entry in basedir/user.htm.

x

If you are using Managed Reporting administered DBMS authorization, you should create domains with the Developer Studio and/or Domain Builder applet tools, and you can skip this section.

If you are using an externally administered configuration, you have two choices.

• Create/delete/rename domains with the standard Managed Reporting tools, and manually synchronize the domain information with the external repository. If you plan to use the cmload utility to create domains in the target repository, you must define the external domain reference before running cmload.
• Create/delete/rename domain information in the external directory, and allow it to be created dynamically as described in Understanding Sign-on Processing with External Authorization under step 6.

Either approach is supported, but it is important to enter your domain ID in the external directory with exactly eight alphanumeric characters (and no spaces or special characters).

• When using the WFMR_LdapSecurityManager, you should enter the eight character domain ID as a suffix within the Active Directory/LDAP group name (for example, test_ibimr-dmn_domain04). You should also provide a description that will be displayed to users in the tools.

  

  For more information, see Using Active Directory Application Mode.

• When using the WFMRX_DBSecurityManager, you would enter the eight character domain ID, the domain name, and none for the properties field if you want to add them to the table directly (the Description column is for future use and can be left empty).

You can enter information about a new domain in an external repository like the following:

The repository will be created in Managed Reporting as shown in the following image:

Important: If you define domain href values in your external directory with spaces or fewer or more than eight alphanumeric characters, Managed Reporting will use an eight character reference (padded with random characters) to create the domain storage and reference objects and will be unable to locate them.

x

In Configuring Managed Reporting for Trusted or External Authentication, specific recommendations and requirements are given for how to prepare Dashboard and ReportCaster for trusted or external authentication. When configuring external authorization, you need to be aware of the following additional requirements.

Note: If you are using DBMS authorization, you can skip this section unless you plan to manage your authorizations externally (without the MR Administration interface). The public and admin users are created properly by the MR Realm Driver DBMS Configuration Utility.

The service account specified for Public Views in the Dashboard ViewBuilder interface (for example, public or ibibidsvc) must be defined in the external authorization directory with the following characteristics:

• It should have the Managed Reporting role User.
• It should be associated with the desired Managed Reporting Groups.
• It should not have any other Managed Reporting privileges.

The default administrator account specified in the ReportCaster Server Configuration tool (for example, admin or ibircsvc) must be defined in the external authorization directory with the following characteristics:

• It should have the Managed Reporting role MR Administrator.
• It does not need any Managed Reporting Groups or additional privileges.