We are being arm-twisted into merging two completely different environments into one, but somehow keeping everything separate - we do not want users of one group to run reports of the other group, we do not want the developers of one group to edit the programs of the other group.

I've tried several scenarios but every time I make one small change to security or some other parameter - things get messed up.

Current Environment 1:
Self-service app that uses MRE for security - login screen logs in to MRE and then navigates to a self-service parameter screen. Generic User ID with non-expiring Password is used for database access.

Current Environment 2:
Self-service app that uses it's own security to validate user access. User ID and expiring Password is used for database access.

New Combined Environment:
We were told by Information Builders to use "APPLOCK" (Technical Memo 4613: Creating Private Application Views With APPLOCK). Convert Environment 2 to login to MRE and then use App Path defined for the logged-in user. This means every User in Environment 2 must be added to MRE and also every user must have a profile on the reporting server - this sets the App Path. Then in Developer Studio, the user must log in to MRE to have the available Self-service App Folders only be the ones based on the user App Path Profile. Dev Studio does not seem to login to MRE automatically - you have to click on the MRE icon to log in every time you open Dev Studio.

All this seems counter intuitive and annoying, and I can't make it work perfectly for the two different types of users.

Does anyone have any ideas?

This message has been edited. Last edited by: Kerry,

One idea is to create an additional service in the WebFOCUS Reporting Server, specify a new node (server) in the odin.cfg to point to this service.

One application would use the default server node and the other application would use the new server node.

You could then use a service profile to set the app path.

Francis,
What are you presently running for security on the Reporting Server? Depending on what you're using might open up different options.

e.g. With LDAP security on the Reporting Server you can use group profiles based on an LDAP group instead of having individual user profiles.

As far as the merging of the environments are concerned, based on your description I don't see why you'd have to add the second environment to Managed Reporting if you're happy with the level of security you presently have in that environment.

APP LOCK is implemented at the Reporting Server level. Since APP LOCK that is going to keep your MAS and FEXes on the Reporting Server from being accessible from other users, whether Managed Reporting is in the picture really doesn't mater.

APP LOCK does not do anything with Managed Reporting content and it will only limit the MAS and FEXes that come from the Reporting Server. It will not impact the domains, or FEXes within the MR content.

In addition if you want Developer Studio to log into Managed Reporting automatically you can save your credentials within the environment configuration. The prompt for credentials should also have a "remember" checkbox.

Thanks,
Doug Logan

bhearn, a very intriguing idea, thank you. Would this affect WebFOCUS licencing? The goal of this is to reduce the number of licenses.

Regards,

It definitely would not require another WebFOCUS Client license, and I believe it would not require another Reporting Server license.

However, if you check with your local branch they should be able to verify.

You would still only be using one Reporting Server instance, just with multiple services under the one reporting server so it should not require an additional license. But yes, check with your local IBI rep.

This is also a good technique to separate the report requests from your adhoc (Report Assist or Info Assist) users and your standard parameterized report users (to minimize the impact of any run away adhoc requests from affecting your standard report response times as each service can be tuned differently - max cpu limit, memory limit, etc).

We something similar for our RC requests and external user scheduling where authentication is hard-coded for system access. External self-service applications contain their own security but use a system account for WF access. All other access is through MRE.