Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [CLOSED] Adapters and profiles - limiting users access

Read-Only Read-Only Topic
Go
Search
Notify
Tools
[CLOSED] Adapters and profiles - limiting users access
 Login/Join
 
Silver Member
posted
Hello,

I was wondering if people could tell me if my approach to security made sense here and if my understanding is right re adapters and profiles and their interaction and if I am wrong give a pointer not to do this if it will cause issues.

I am thinking on SQL server create several logins - (SAL, INV for example), then create users in database attached to those logins, then create schemas within that database (eg sal. or inv. or gen.) , then grant all users access to the gen. schema (containing information not to be ringfenced) and their own schema.

Then create adapters based on the users created in SQL server (SAL, INV etc). Then create master files with the acx's having the relevant connection.

Next create the profiles and in the EDASPROF put the GEN adapter in there (and only that one) and in the group profile have the users respective adapter visible (SAL for SALES, INV for Inventory). Leave the user profiles empty.

How does it sound? this might be the wrong place to ask but here is question anyway. Note, once a master file has been created a user can't run a report on the master file unless they can see that adapter is that right?

Regards

This message has been edited. Last edited by: FP Mod Chuck,


WF 8201, Windows Server 2012 R2, SQL Server 2014, HTML, PDF, Excel, Powerpoint, Active Report
 
Posts: 34 | Location: All over Europe | Registered: October 23, 2009Report This Post
Virtuoso
posted Hide Post
otto

Yes that does make sense but if they do run a report the error message that the adapter connection could not be found may be a bit confusing to them.

Another way to prevent them from using master files you don't want them to see is to segregate them into different application folders and use the server side security to only allow them access to those folders based on their security group.


Thank you for using Focal Point!

Chuck Wolff - Focal Point Moderator
WebFOCUS 7x and 8x, Windows, Linux All output Formats
 
Posts: 2127 | Location: Customer Support | Registered: April 12, 2005Report This Post
Guru
posted Hide Post
What you normally see nowadays is that you authorise users on client (WFC). WFC provides the most options for authorisation. Ideally you won't even publish the reporting server for normal users.

Check out the documentation, there is a lot to learn about it.

You need to think about a concept, what kind of users do you have, does each group have own databases, own reports, or do they share a lot. Is there any privacy sensitive info that needs to be protected. If you have this kind of info you can set up a model. Sometimes this is based on sourcesystems, sometimes on functional groups, sometimes on organsation, etc. Based on this you can make a setup. Profiles are fine to give users db access, but keep in mind the sql optimization won't work if you join data adapters. Then there is also the option for DBA security for row based security.

But take it step by step, first check how your usergroup and reports can be grouped.


Test: WF 8.2
Prod: WF 8.2
DB: Progress, REST, IBM UniVerse/UniData, SQLServer, MySQL, PostgreSQL, Oracle, Greenplum, Athena.
 
Posts: 454 | Location: Europe | Registered: February 05, 2007Report This Post
Master
posted Hide Post
otto it is really hard to say what is best as it totally depends what your security is. But lets say you are using Kerberos or OPSYS on windows. You can pass the Kerberos ticket or make a trusted connection all the way thru to the database. This will allow the database to know exactly who is coming in. You then would create database roles and either assign users to the roles or AD Groups for instance. Then you could created separate schemas and grant select on the schema for a role. Or just use 1 schema and grant all roles select on that schema and use views that would check to see if a uses is a member of the approved role. you could also use this to limit what data a user can see from the views.




Scott

 
Posts: 865 | Registered: May 24, 2004Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [CLOSED] Adapters and profiles - limiting users access

Copyright © 1996-2020 Information Builders