MRE: Limit users to only dashboard?

Greetings,

We have a mix of users in our MRE environment, some using MRE applet, and some that are deployed to only Dashboard group views (no tree). We would like to prevent the Dashboard-only users from logging on to the MRE via applet. Is there a way to do this?

Regards,

Dan Kenny
University of Nebraska at Omaha
Prod: WF 7.1.5 Test: WF 7.6.0

Posts: 63 | Registered: March 07, 2006

posted

Hi Dan,

Unfortunately, the Managed Reporting is the Dashboards Repository. All the Users, Groups and Domains get created in Managed Reporting. If a user has access to the Dashboard they will also have access to the Managed Reporting.

Please let me know if this answers your question.
Regards,
Monica

BlueZone

Platinum Member

posted

Hide Post

Monica is right on the money Dan.
When we deployed BID after having MRE for a while before that, we had the same problem. Here is what we did to get around it ....

#1> We disabled the then-current MRE URL and all other internal self-serv app URLs (with a msg on some to contact the WF-Admin if they are still stuck on it).

#2> Defined a new MRE log-in page Alias that we shared only with the Power-user (developer) types that continued to have the MRE. Our security policies informed them NOT to share this URL with other users, but always contact the WF-Admins in such cases. (But ofcourse, we are still at their mercy as much as enforcing those security policies go).

#3> Deployed BID-GroupViews and distributed them to their respective users, who now use them instead of the old MRE or SSA links.

Not exactly fool-proof, but this methodology worked for us.

Gooooooooood luck with yours !!
Sandeep.

-------------------------------------------------------------------------------------------------
Blue Cross & Blue Shield of MS
WF.76-10 on (WS2003 + WebSphere) / EDA on z/OS + DB2 + MS-SQL
MRE, BID, Dev. Studio, Self-Service apps & a dash of fun !!

Posts: 218 | Location: Jackson, MS | Registered: October 31, 2006

Ignored post by BlueZone posted

Show Post

Dan Kenny

Gold member

posted

Hide Post

Thanks for the responses and suggestions, it is much appreciated.

I was hoping to be able to differentiate the client access path (MR applet verses WORP) and lock them at the server level after authentication but I guess I'm stuck with just manipulating the login screen.

Sure would be nice to be able to tell if someone came in from which client, whether it was Dev Studio/MR Developer, MRE applet or Dashboard, and be able to lock access based on userid or group affiliation. Dashboard has some nice features for tailioring the interface to a domain (role-based and specific content block layouts), but it all is rather leaky from a security standpoint if users can poke around the domain via MRE applet.

Regards,

-- Dan

University of Nebraska at Omaha
Prod: WF 7.1.5 Linux Test: 7.6.0 Linux

Posts: 63 | Registered: March 07, 2006

Ignored post by Dan Kenny posted

Show Post

BlueZone

Platinum Member

posted

Hide Post

That is a very good point Dan, one that is worthy of sending to IBI as a NFR.

It sure would be nice to be able to differentiate the User types.

Sandeep M.

Posts: 218 | Location: Jackson, MS | Registered: October 31, 2006

Ignored post by BlueZone posted

Show Post

Francis Mariani

Expert

posted

Hide Post

There IS a way to tell where the user came from.

Read these postings:

https://forums.informationbuilders.com/eve/forums/a/tpc/...961093381#2961093381
https://forums.informationbuilders.com/eve/forums/a/tpc/...771034591#3771034591

They explain how to add HTTP Header Variables.

There's one called HTTP_REFERER, this gives you the URL of where the request was made from.

Once you set up this HTTP Header Variable, it becomes a Dialog Manager variable that can be accessed from any WebFOCUS program. You can add WebFOCUS code to edasprof.prf to verify where a user came from.

--

Reference: Check out the WebFOCUS Security and Administration manual. Look for "HTTP Header Variables Available for Script Processing".

Francis

Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server

Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005

Ignored post by Francis Mariani posted

Show Post

Dan Kenny

Gold member

posted

Hide Post

Thanks, Francis --

Those are very useful informational links, in more than just the present task. I will experiment with variables passing.

The biggest challenge with applying this approach is that we have many MRE applet users that ALSO use Dashboard group views. I do not relish the approach of having to hard-code userids into edasprof.prf in order to prevent the dashboard-only users from using MRE applet. This maintenance problem might be made less if I can lock onto their group names and hard-code those tests in edasprof.prf, but it all seems quite kludgy and maintenance-intensive.

It would be so much easier if we could have check boxes on each userid that included "applet" like we do for "advanced" and "schedule".

Regards,

Dan Kenny
University of Nebraska at Omaha

Posts: 63 | Registered: March 07, 2006

Ignored post by Dan Kenny posted

Show Post

Francis Mariani

Expert

posted

Hide Post

Dan, I agree that managing the user's access rights through the MRE User Administration tool would be the best way.

Cheers,

Francis

Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server

Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005

Ignored post by Francis Mariani posted

Show Post

Please Wait. Your request is being processed...