Configuring WebFOCUS for External Authentication ... · • Understand why it’s important to integrate WebFOCUS Client and Reporting Server security. • Become familiar with Server

Configuring WebFOCUS for External Authentication/Authorization

Jim Thorstad and Maria Trofimova Information Builders

Summit 2014 User Conference June 3, 2015

Author: Jim Thorstad and Maria Trofimova Company: Information Builders Lab Title: Configuring WebFOCUS for External Authentication/Authorization Abstract: In this lab you will configure WebFOCUS to authenticate and authorize users to Active Directory and use the Reporting Server access control feature to authorize users to Application directories. This makes it possible to tightly integrate WebFOCUS into your organization's infrastructure for an installation that's more secure and easier to administer.

Configuring WebFOCUS for External AuthN/AuthZ Page 1 of 41 5/24/2015 Copyright © 2015 Information Builders

Lab Goals

• Learn how to configure WebFOCUS to authenticate and authorize to Active Directory and what the benefits are.

• Understand why it’s important to integrate WebFOCUS Client and Reporting Server security. • Become familiar with Server Access Control and how it can be used to control access to

Application directories on the Server. • Discuss how to authorize users based on data in a relational DBMS table.

Business Case In this lab you will configure WebFOCUS to authenticate and authorize users based on information stored in Microsoft Active Directory.

Benefits of authenticating to Active Directory:

• Improved usability – users only need to remember a single user ID and password.

• Reduced administration – WebFOCUS synchronizes user information with Active Directory.

Benefits of authorizing to Active Directory:

• Reduced administration – WebFOCUS automatically creates user accounts and administrators can centrally manage access to all applications.

• Improved security – authorization is verified during each sign-in or scheduled job execution.

Pre-authenticating users with their Windows Desktop credentials is a very popular option you should consider, but it is not covered in this lab. For more information please watch this video: http://techsupport.informationbuilders.com/tech/wbf/WFVideos/WFSEC02.mp4


http://techsupport.informationbuilders.com/tech/wbf/WFVideos/WFSEC02.mp4

Lab Personas During the lab you will interact with WebFOCUS in a number of different roles.

Allison Wells WebFOCUS Administrator

Active Directory Credentials:

User ID: aw01

Password: Password1

Groups: COR-IT-BIADMIN. COR-IT-BISUPPORT

Allison is the lead BI administrator. She will be internally authorized to WebFOCUS and to the Reporting Server.

Tony Bishop WebFOCUS Administrator (backup)


User ID: tb01

Password: Password1

Groups: COR-IT-BIADMIN

Tony is Allison’s backup; we’ll use him to demonstrate how WebFOCUS administrators can be externally authorized

Calinda Walters Account Manager, Chicago Office


User ID: cw01

Password: Password1

Groups: BRA-CHI-SALES

Calinda works in a sales office; we’ll use her to demonstrate how a wildcard mask in the group mapping value can be helpful.

Paul Henderson HR Manager who has been using FOCUS for years


User ID: ph01

Password: Password1

Groups: COR-HR-MGRS

Paul is a report developer; we’ll use him to demonstrate how Server Access Control can be used to govern access to Application directories.

Task 1 – Configure an LDAP Security Provider on the Reporting Server You will begin the lab as Allison Wells, the WebFOCUS administrator. Your first task is to create an LDAP security provider on the Reporting Server that will authenticate users to Active Directory (AD), retrieve their full name and email, and retrieve the AD groups they belong to.

1. Open Chrome from the Windows Taskbar. In this lab, Allison will always use Chrome to access the Server Console

2. Click on the 81 Seclab Console shortcut on the Chrome favorites bar.


3. Sign in to the 8.1.00 Server Console with the following credentials:

• User ID: srvadmin

• Password: srvadmin

4. You are signed in as a Server Administrator. Click on the Access Control tab.

5. Notice that the Server is currently running with its PTH security provider active.

PTH<internal> refers to the Server’s Process Table Handler (PTH) module; the Server’s internal security provider.

6. Right-click the Security Providers > LDAP node and then select New.

7. In the LDAP Security Configuration panel, click Continue.


8. Make the following changes and then click Next. • ldap_host: ibsummit.local • security: Explicit • ldap_principal: [email protected] • ldap_credentials: Password1

IMPORTANT: You should select the Explicit option when authenticating WebFOCUS users to Active Directory. Also, be sure the account specified for ldap_principal has a non-expiring password in Active Directory.


9. The Server makes an LDAP connection to the directory and determines it is Active Directory. The Server fills in typical values for Active Directory in the User Search panel. Don’t change these for the lab, but in practice you should review the settings with your Active Directory administrator.

10. Click the expand button in the Group Search properties accordion bar. You can also collapse the User Search accordion bar if you like.

11. Again, the Server fills in typical values for Active Directory here. Leave these unchanged.


12. Click the expand button to advance to the Trusted Connections property.

13. Change trust_ext to y and then click the Test button.

The trust_ext=y setting specifies that the Server should accept trusted connections coming from WebFOCUS. After sign in, the Server will not make any further connections to AD for the user. Tip: you should take steps to ensure that unauthorized WebFOCUS Clients cannot connect to the Server after enabling trust_ext=Y such as using network or host firewalls or using the RESTRICT_TO_IP setting on the Server’s TCP and HTTP Listeners.

14. In the test dialog, enter Allison’s AD credentials and then click Continue.

• User Name: aw01

• Password: Password1

15. Allison’s credentials were verified and the names of her AD groups are displayed.


16. Close the test dialog by clicking the X in the upper right corner.

17. Click Save to create your new LDAP security provider.

18. Change LDAP provider status to Primary.

19. Notice that PTH is automatically changed to Secondary.

The documentation recommends leaving PTH as a secondary security provider because:

• You can access the Server Console even when Active Directory is unreachable.

• You can specify a PTH service account in WebFOCUS for connecting to the Server. Note: the security provider transition process is a little different in the 8.0 (7.7.05M) Server but the concepts are the same.


20. Click the Save Provider’s Status button.

21. The next panel confirms that you are enabling two security providers and that PTH\srvadmin will be the only valid Server Administrator ID after restart. You are also advised to consider securing the file system and functional privileges that these LDAP users will have on the Server Console—we’ll revisit this later in the lab. Click the Apply and Restart Server button.

22. Minimize the Chrome browser session and continue to the next task.

You will return to Allison’s Server Console session later in the lab.

Task Summary: Allison configured an LDAP security provider that can authenticate users to Active Directory and retrieve user information, which includes name, email, and group membership details. She specified that the LDAP provider accept trusted connections and she configured PTH as a secondary security provider.


Task 2 – Create the Initial WebFOCUS Administrator In this task Allison will create a WebFOCUS administrator account spelled the same as her AD account (aw01). This is necessary because once WebFOCUS is configured to authenticate to AD she will need to sign in to WebFOCUS with AD credentials.

1. Open Internet Explorer from the Windows Taskbar.

2. Sign in to WebFOCUS using the following credentials:

• User Name: admin

• Password: adminx

3. From the Administration menu select Security Center.

4. Click the New User button.


5. In the New User dialog box make the following two changes and then click OK.

• User Name: aw01

• Description: Leave blank; this will be sychronized with AD during sign in.

• Email Address: Leave blank; this will be sychronized with AD during sign in.

• Password fields: Leave blank; internal passwords are ignored in the new configuration.

• Create in Group: Administrators

6. Click the Administrators group in the Groups pane. Confirm aw01 is shown in the member list.

7. Click Close to exit Security Center. Remain signed in as Allison, and continue to the next task.

Task Summary: Allison created a WebFOCUS administration account spelled the same as her AD account. She can use this account to manage WebFOCUS when it has been reconfigured to authenticate to AD.


Task 3 – Configuring a Trusted Connection to the Server In this task Allison will reconfigure WebFOCUS to make trusted connections through the SECLAB81 Server node and make this the default node. Trusted connections improve performance because the Server only connects to AD during sign in; there are no connections when users run reports. Trusted connections also allow WebFOCUS to pass the user’s WebFOCUS groups to the server. We’ll use this feature later in the lab to control Paul’s access to Server Application directories.

1. Select Administration > Administration Console from the menu bar.

2. Select Reporting Servers > Remote Services on the left hand side.

3. Select the SECLAB81 server node and then click Modify

4. Select Trusted in the SECURITY section.


5. Then click Save.

6. Select the SECLAB81 node again and then select the Set as Default Server Node option.

7. Leave the IBI_REPORT_USER and IBI_REPORT_PASS parameters blank and click Save.

These are legacy parameters not relevant to a trusted connection.

8. Hover over the SECLAB81 node. Notice the new keywords related to security.

9. Remain on this Console page and continue to the next task.


Task 4 – Configuring WebFOCUS for External Authentication and Authorization In this task Allison will configure WebFOCUS to use the Server and its LDAP security provider to authenticate users and return their AD user and group information.

1. Select Configuration > Security from left side of the Administration Console.

2. Make the following changes:

• IBI_Authentication_Type: WFRS

• IBI_Update_User_Info: True

• IBI_User_Group_Membership_ExtAuthN: EXTERNAL

• IBI_External_Group_Type: WFRS

• IBI_WFRS_Service_User: PTH\srvadmin

• IBI_WFRS_Service_Pass: srvadmin

• IBI_WFRS_Authentication_Node: SECLAB81 • IBI_User_Password_Change: False


3. Scroll down to set the WebFOCUS superuser credentials and click Save.

• IBI_Admin_Name: allison

• IBI_Admin_Pass: redsox

Tip: In the event that WebFOCUS is misconfigured or the Server is down, Allison can sign into WebFOCUS using these superuser credentials. It’s not necessary to create a WebFOCUS account for the user specified by IBI_Admin_Name and this does not need to be an Active Directory account.

4. Click Close in the Administration Console banner.

5. Click Sign Out from the WebFOCUS banner.

6. Close Internet Explorer and continue to the next task.

Task Summary: Allison configured WebFOCUS to authenticate and authorize users to the Server. She also set the superuser credentials so she can access WebFOCUS in the event she’s misconfigured something.


Task 5 – Configuring WebFOCUS Security Tracing In this task Allison will configure the com.ibilog logger so she can see detailed security messages in the WebFOCUS event.log. Before going into production she will return the log level to its original value.

1. Open the Utilities folder on your Windows desktop.

2. Open the Security Lab folder.

3. Double-click the log4j shortcut. Click No if prompted to update the Notepad++ software and Cancel the Plug-in Manager dialog.

4. On line 490 carefully change the com.ibilog level value from info to trace.

5. Click Save.

6. Close Notepad++.

7. Close the Windows Explorer window.

8. Open Windows Services from the Taskbar.

9. Right-click Apache Tomcat 7.0.33 for WebFOCUS service and select Restart.

10. Close the Services dialog and the Utilities folder and continue to the next task.


Task 6 – Testing External Authentication In this task Allison will test the new external authentication configuration. However, because she has not yet mapped any WebFOCUS groups to AD groups, she will be internally authorized. This is why is was necessary to create the aw01 account using Security Center (Task 2) and place it into the WebFOCUS Administrators group. Allison will use the TailMe utility to see security messages in the WebFOCUS audit.log and event.log, as well as the Server’s edaprint.log.

1. Open Internet Explorer from the Taskbar.

2. Before signing in, click the TailMe icon on the Taskbar.

3. Position Internet Explorer and TailMe so they each occupy about ½ of the screen width.

4. Sign in to WebFOCUS with Allison’s Active Directory credentials.

• User Name: aw01


5. Notice that Allison’s full name now appears in the menubar, even though you left the user description property blank when you created her account in Security Center (Task 2).

This is because you set IBI_Update_User_Info = True in Task 4.


6. TailMe shows messages written to the WebFOCUS audit.log, event.log, and the Server edaprint.log (from top to bottom). The log level change you just made enables the useful DEBUG/TRACE messages in the event.log (middle panel).

Tip: If you see an error like this below in your edaprint.log, you mistyped the password for IBI_WFRS_Service_Password which should be “srvadmin”. You will need to sign in using the superuser credentials and fix the error using the Administration Console.

7. Leave the TailMe program open and leave Allison signed into WebFOCUS.

8. Continue to the next task.

Task Summary: Allison has configured WebFOCUS to authenticate and authorize users to Active Directory, via the Server’s LDAP provider. You’ve also seen how to enable detailed tracing in the event.log to help troubleshoot configuration and authorization problems.


Task 7 – Externally Authorizing WebFOCUS Administrators In this task Allison will map a subgroup underneath the Administrators group to the AD group COR-IT-BIADMIN, so her teammates can help manage WebFOCUS. By leaving the parent group Administrators as an unmapped group, Allison retains the ability to assign WebFOCUS administrators internally as well.

1. Select Administration > Security Center from the WebFOCUS menubar.

2. In the Groups list, right-click the Administrators group and select New.

3. Enter External for the Group Name and then click the Browse… button.

4. In the Search field enter COR* and then click the Search icon.


5. Select COR-IT-BIADMIN and then click the >> icon to move it to the right-hand side.

In the TailMe window, find the get groups message in edaprint.log.

6. Click OK to select the external group mapping.

7. Click OK again to save the external group mapping.

8. Notice that the mapped subgroup is now shown with a different icon. Hover over the mapped group to reveal its mapping property.

9. Close Security Center.

10. Click Sign Out from the WebFOCUS menubar. Task Summary: You can create and map subgroups to external groups as a way to allow group membership to be managed both internally as well as externally.


Task 8 – Testing External Authorization

In this task Tony will sign in to WebFOCUS for the first time. He will be externally authenticated and authorized based on his membership in the AD group COR-IT-BIADMIN.

1. Open TailMe from the Windows Taskbar.

2. Sign in to WebFOCUS using Internet Explorer and the following credentials:

• User Name: tb01


3. Notice the “createUser” message in the audit.log, as well as messages about the assignment of our InfoAssist/Data Visualization seat licenses.

4. Select Administration > Security Center from the menubar.

5. Scroll to the bottom of the user list and see that Tony’s account status is AUTOADD.

AUTOADD is controlled by the value of IBI_Allow_Login_External_Groups:

• *MAPPED* - an account will be created if the user belongs to any mapped group.

• * - an account will be created for all authenticated users

• Group1;Group2 - an account will be created only if the user belongs to the specified external group names. This is useful if you want to manage the number of authorized users by using a special external group like COR-IT-WFUSERS.

6. Close Security Center.


7. In WebFOCUS, right-click the Content Node and select New > Enterprise Domain.

8. In the dialog, enter the following and click OK.

• Name: HR

• Description: Human Resources

9. Click OK when the confirmation dialog appears.

10. Click Administration > Security Center and then expand the HR group on the right.

11. Right-click the HR/Developers group and select Edit…

12. Click the Browse… button.


13. Replace the Search field contents with COR-HR* and then click the Search button.

14. Select Paul’s group COR-HR-MGR and then click the >> button.

15. Click OK, and then click OK again to save the external group mapping.

16. Hover over the HR/Developers group to confirm the mapping.

17. Click Close to exit Security Center.

18. Click Sign Out in the WebFOCUS menubar and continue to the next task.

Task Summary: You learned how IBI_Allow_Login_External_Groups, group mapping, and the user’s external groups work together to determine whether an account will be AUTOADDed during their first sign in. You also learned how to map groups created by the built-in resource templates. You can also develop a custom resource template that automatically maps groups to your organization’s external groups; this greatly simplifies administration and more tightly integrates WebFOCUS security with your corporate processes.


Task 9 – Understanding External Authorization with Wildcard Mapping In this task we will discuss how a wildcard mask can sometimes be a better option than mapping multiple external groups to a WebFOCUS group.

Consider that you want the entire field sales team to have Basic User access to the Sales Domain. These users exist in many Active Directory groups, including: BRA-BOS-SALES, BRA-CHI-SALES, and so on. You could select all of these groups in the Browse External Groups dialog as shown below.

But what if a new sales office opens up in San Francisco and users in this office are assigned to a new AD group BRA-SFO-SALES? You would then need to edit the group mapping in your production WebFOCUS environment before San Francisco users could see the Sales domain.

An alternative is to simply type a wildcard mask for the mapping property, rather than using the browse feature.

This way members of any Active Directory group that begins with “BRA-“ will be authorized to the Sales/BasicUsers group.


Task 10 – Registering WebFOCUS Groups to Server Roles In Task 1 you configured the Server to accept trusted connections and then in Task 3 you configured the WebFOCUS Client to make trusted connections. In this configuration the Client passes the WebFOCUS user ID and group list of authenticated users to the Server.

In this task you will register specific WebFOCUS groups to specific Server Roles so that members of these groups will have the proper privileges in the Server Console when they connect to it through WebFOCUS. This creates a better user experience and simplifies administration.


• User Name: aw01

• Password: Password1 Show that going to server console from WF tree results in Allison being a regular console user; this is not what we want.

2. When Web Console opens, click Console button on the top and select Login Info.


3. The Login Info page shows that user aw01 that is member of EVERYONE and Administrators groups, has been assigned the server role of Basic user, and has made a trusted connection.

The reason Allison has been assigned the Basic User role on the Server Console is because her User ID (aw01) and groups (EVERYONE, Administrators) have not been given any specific rights on the Server and therefore her connection is assigned the default rights as determined by the Server’s default_admin_role setting.

Now we will register the WebFOCUS Administrators group to the Server’s Administrator Role so that members of the WebFOCUS Administrators group can manage the Server more easily.

4. Close the Server Console window and Sign Out of WebFOCUS.

5. Switch to Chrome. Due to the Server restart you will need to sign in again.

6. Select PTH from the Security Provider list and enter srvadmin for the User ID and Password.

7. Click the Access Control tab.


8. Right-click Roles > Server Administrator and then select Register Group.

9. Click the Single Group Registration button.

10. Enter Administrators for the Group and click Register.

11. Click OK to confirm.


12. Click on the Group Members tab.

Notice that the Administrators group registration is prefixed with the Server’s ldap01 security provider and that the Group Members list contains groups from Active Directory’s Administrators group. These two things happen because the Server has a setting trusted_group_default_provider which is defaulting to ldap01, as shown below.

When an unqualified group name is passed to the Server on a trusted connection, the Server considers it to be associated with the security provider specified by the value in trusted_group_default_provider. But this also means that members of the Active Directory Administrators group, who might access the Server Console directly, will be associated with the Server Administrator role. The trusted_group_default_provider parameter is new in the 8.1 (7.7.06) Server, but this behavior also occurs in the 8.0 (7.7.05) Server.

Let’s register the WebFOCUS HR/Developers group.

13. Right-click Roles > Application Administrator and then select Register Group.


14. Click the Single Group Registration button.

15. Enter HR/Developers (with a forward slash) for the Group and click Register.

At runtime WebFOCUS passes Paul’s groups as g=HR,HR/Developers,EVERYONE so we must spell the Server group registration “HR/Developers” including the mixed case.

16. Click OK to confirm. The group is registered.

17. Leave the Chrome Server Console session running; we’ll need it in the next Task. Now let’s Test out these Server changes.

18. Open the Internet Explorer web browser.


• User Name: aw01



Right-click the Security Lab reporting server node and select Reporting Server Console.

20. When Web Console opens, click Console button on the top and select Login Info.

21. Because you registered the WebFOCUS Administrators group (showing up below as ldap01\Administrators, for the reason explained previously), Allison now has Server Administrator privileges on the Server Console.

Note: when a report is run or the list of MFDs is requested the order of groups is:

22. Close the Server Console window and Sign Out of WebFOCUS.

23. Sign in to WebFOCUS as Paul using:

• User Name: ph01



24. Open the Server Console from the Reporting Server node again. Then check the Login Info page.

Paul now has Application Administrator privileges on the Server Console. Notice that Paul’s Server Console shows only a few Application Directories whereas the Client Reporting Server tree shows many more. Adjust the windows so you can see this.

25. Click on the Application Preferences button on the Server Console Ribbon.


26. Select the Show Applications not in PATH option and then click the Update button.

27. Notice now that the Server shows all the Applications; those not in APP PATH are shown in the Inactive Directories folder.

The Client and Server simply have a different way to organize the Applications. What if we don’t want Paul to have access to all these directories? Clearly APP PATH alone is not sufficient to authorize Application directories. And you cannot rely on the App Path property on Domain folders since this doesn’t affect behavior of the Reporting Server node or Server Console.

28. Leave Paul signed into WebFOCUS and continue to the next Task.

Task Summary: You learned how to register WebFOCUS Groups to Server Roles so that users who connect trusted to the Server Console have the correct privileges. You also observed that the order of groups passed depends on whether the request is to the Server’s HTTP or TCP listener, and that groups which are registered to server roles have a security provider prefix depending on a server setting.


Task 11 – Using Server Access Control to Authorize Application Directories In the last task you saw that both Allison and Paul were able to see all the Application folders on the Reporting Server, despite the fact that only a few were in the server’s APP PATH. This is because by default the Server’s APPROOT uses an “Open” security model where everyone has access to everything.

In this task you will change the APPROOT to a “Closed” model where no one has access to anything unless it is explicitly granted. Then you will explicitly grant the members of the WebFOCUS HR/Developers group acces to specific Applications. This is the recommended model for most deployments.

1. Switch to Chrome, with the PTH/srvadmin session still active.

2. Click the Access Control tab.

3. Right-click the Application Administrator role and select Properties.

4. Although we are not doing it in this lab, this is the place you would restrict the Server’s functional privileges for users associated with this Server Role. For example, you could check NOSYS to prevent the user from issuing Operating System commands from within a FOCUS procedure.


5. Click the Directory/File Privileges tab.

6. We need to add a Directory entry for APPROOT and then remove all privileges from it. Right-click on ibi and select Register Directory/File.

7. Click on the File Picker.

8. In the search dialog, click apps on the right pane and then click OK.

9. Click Next and to register D:\ibi\apps.

10. Click the box in the first row to deselect all of the privileges at once and then click Apply.


11. All of the privileges should be cleared and you will see a Registered status on the right.

This configures a closed APPROOT for Application Administrators. Tip: To complete the closed model configuration, Allison would need to perform similar steps to clear privileges on APPROOT for the Server’s Basic User role. But we will skip that step due to time constraints in the lab.

At this point users registered to the Server’s Application Administrator role cannot access anything in APPROOT, regardless of what is in their APP PATH. But then how do we give these users access to the Application folders they require? Let’s say Paul, who belongs to the HR/Developers group, which is registered to the Server’s Application Administrator role needs read/write access to ibisamp but read-only access to server_lab.

12. Now click on the Applications tab.


13. Right-click the ibisamp Application and select Privileges.

14. Right-click (or double-click) the ldap01\HR/Developers entry and select Edit Privileges.

15. Check the box in the first row and then click Apply.

16. This grants HR/Developers full access to the ibisamp Application directory.


Now let’s repeat the steps for the server_lab Application except that we won’t give Write privileges.

17. Right-click the server_lab Application and select Privileges.

18. Right-click (or double-click) the ldap01\HR/Developers entry and select Edit Privileges.

19. Check only the AREAD, and PRRUN, and ALIST boxes and then click Apply.

20. This grants HR/Developers read-only access to the server_lab Application directory

21. Leave the Chrome Console session running and switch back to Internet Explorer.

22. Expand WF Server 81 tree (right-click and select Refresh if necessary). Notice only the two Application folders plus foccache are shown.


Note that application ibisamp, server_lab, and foccache are available

23. Explore the right-click options Paul has on the ibisamp and server_lab folders. Notice that they are respecting the Server privileges you just registered.

Task Summary: In this task you learned how Server Access Control can be used to assign Application directory access privileges to members of WebFOCUS groups through the group registration process.


When there are many Applications and there is a pattern between the WebFOCUS group names and the Application names you can use Server Access Control Templates to automatically assign the access rights, greatly simplifying security administration and providing a more integrated security environment between WebFOCUS and the Server.

Refer to this document for more information about Server Access Control Templates.

http://techsupport.ibi.com/tech/wbf/v8templates/ac_template_example.pdf


http://techsupport.ibi.com/tech/wbf/v8templates/ac_template_example.pdf

Task 11 – Understanding External Authorization to RDBMS Data In this task you will see how Allison can externally authorize customers for a new reporting application based on information stored in a relational database table that is maintained by the customer support application.

You can map WebFOCUS groups to external data in a RDBMS table in the same way that you mapped groups to external group data in Active Directory.

1. Using Chrome, click the Tutorials button on the ribbon.

2. Select WebFOCUS - Custom SQL Security Provider from the list

3. Select WFSQL_PROVIDER from the Adapter List.

4. Click OK when prompted to continue.


5. The following confirmation dialog comes up with next steps described.

6. If you are using the 8.0 (7.7.05M) Server, you can download a sample WFSQL provider from: https://techsupport.informationbuilders.com/tech/wbf/v8templates/wbf_8_server_custom_provider.html


https://techsupport.informationbuilders.com/tech/wbf/v8templates/wbf_8_server_custom_provider.html

Documents

Configuring WebFOCUS for External Authentication ... · • Understand why it’s important to integrate WebFOCUS Client and Reporting Server security. • Become familiar with Server