I have a table that I would like to restrict access to all users except for a select group of 12 users that will have access to all of the data.

I have used DBA restrictions many times, but never when dealing with the user base as a whole. Does anyone know how to create a restriction for ALL users and then allow the select few that need all access the ability to see all?

We do not use LDAP so that is not an option for me.

I have seen several discussions over Master File Profiles, but have never used those and haven't found anything on how to set them up or where to go to even set them up.

What I am trying to avoid is having to remember to do maintenance on the DBA restriction list every time we have a user leave or hire someone new.

Thanks,
Jamie

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

Jamie

I see you are still on WF 7.7, is that correct?

Actually, we are on 8105, I need to get that updated.

This is a good starting point for what you're trying to do.
https://webfocusinfocenter.inf...ang/source/ids24.htm

Thanks for the link BabakNYC, I think that a msster file profile might work, but I need a user list. Does anyone know how to extract a user list from the database of all the WF users?

Hi Coyne

Did you understand the doc Babak sent you? Notice the MFD_PROFILE is used to dynamically set an && variable.. Using this approach keeps you from needing to list out every single user under the sun.

Let me pass along the doc from a ways back where maybe the use of a &&UID is more helpful in your situation.

New Feature 7704 MFD Profile info

If that still doesn't help you get started, try explaining what you want to do. Maybe give us a couple of sample users and what they can or can't see.

Also, I would suggest not making your rules based on Users and instead try to make them based off Groups. It's really up to you.

The reason I'm bringing up the dynamic aspect of the MFD_PROFILE and && variables is that, for any one user trying to use the master, Only one DBA rule probably applies. So you don't really need to list everyone all the time.

Better to just dynamically populate a DBA rule for the user who is connected at run time.

shoot us an example with 2 or 3 users and what you want to do if the manuals aren't helping there. I'll see if I can find you anything else on the topic.

Toby Mills, CISSP

Well I learn new things every day! I never saw this GRPLIST function before.

If you're using LDAP to authorize people, you might get some value out of this:

How to obtain the groups a user belongs to in LDAP

While I'm here, let me show you a couple more as food for thought:

How to dynamically build DBA based on multiple LDAP groups

And the old grandaddy of DBA stuff (it's older but still applies):
WebFOCUS Row-Level and Column-Level Security (tm4694)

Since we don't know exactly what you're trying to do, I'm kind throwing out ideas in case any of them are relevant to your use case:

How to restrict the number of records retrieved by a single user query

Coyne15

If you still need to, you can get a list of users from the repository table UOA_USERS the NAME field contains the userid and you want to check for a STATUS of ACTIVE or AUTOADD.

Toby,

Thank you for the information. I will look through it. We are not currently using LDAP so I was trying to accomplish something similar on a per user basis.

Here are some specifics of what I am trying to do.

I have a table of data which includes a column I have called ViewFlag. If the ViewFlag field has an X in it, then I want to restrict users from seeing this record in the data. If the field is blank, then that record is open to all to see. The only 2 values that can be in my ViewFlag field are X and blank.

Normally, I would use DBA Restrictions along these lines:

ALL ACCESS:
USER=JCOYNE, ACCESS=R, RESTRICT=VALUE, NAME=SYSTEM, VALUE=VIEWFLAG NE 'J',$

LIMITED ACCESS
USER=JCOYNE, ACCESS=R, RESTRICT=VALUE, NAME=SYSTEM, VALUE=VIEWFLAG NE 'X',$

And this would accomplish what I need. The reason I would prefer to not use the method for this case is because the list of users is significant as all of our WF users will have the ability to view this report from a Portal. If I am forced to use this method, then I would have to list out each user (over 100) in either the ALL ACCESS or the LIMITED ACCESS section and then maintain this list as people leave the company and new hires come on. The ALL ACCESS list is limited to about 12 people that will not change frequently, but the LIMITED ACCESS list is likely to change monthly. It is the LIMITED ACCESS list that I am trying to manage automatically.

I thought I understood what Babak referenced, but based on your question, I may not sure understand it as I thought. I am not familiar with && variables. Are you suggesting that there is a way to pass a variable that could then determine which access group the person logging in is classified in?

Again, I will look through the links you have provided, but wanted to give you some details.

Thanks,

Jamie

Chuck,
How do you access the repository?

Jamie

Jamie

You have to set up an adapter connection on the WF Reporting Server to the database where the repository resides and then create a synonym for the uoa_users table.

Why not have two master files, one for restricted and another for no restriction ?
Then you either use one of the other according to user.
The restricted master file can then have the DBA feature where the other don't.

Since your non-restricted list is limited you can have it coded.

Sample:

-SET &INFILE = IF &IBIMR_user EQ 'manager1' OR 'manager2' OR 'manager3' THEN 'MY_MASTER' ELSE 'MY_MASTER_RESTRICTED';

TABLE FILE &INFILE
SUM ...
BY ...
END

I'll have to post my final documentation on MFD_Profile.

Check this out for starters.

I would like to join 'The Walters' to present this at Summit 2019...

Martin,
Never tried this method. Thanks for the input.
Jamie

Branching for synonyms... Nice methodology.

But, how do you hide the non-secure synonym from those using IA with access to the app folders? I'm guessing: in a RO?

Great example Doug!

I will have to read and digest all of this, but there seems there should be a solution to my problem here in one of these posts.

Thanks,
Jamie

quote:

But, how do you hide the non-secure synonym from those using IA with access to the app folders? I'm guessing: in a RO?

Can be from a profile or from pre-WF8 using MRE domain security.

quote:

Can be from a profile or from pre-WF8 using MRE domain security.

I like that

quote:

Great example Doug!

That works great for Row Level Security (RLS). Column Level Security (CLS) leaves a little to be desired. But that's also available.

We're using RLS for some heavy duty financials in a portal, and it working out quite nicely.

Thanks Walter

Martin,
None of our users have access to the app folders.

quote:

None of our users have access to the app folders.

They must have in a sense otherwise they won't have access to any master file to run reports.

They access the reports through portals only, so yes they have access, but they are not aware of the how or why they see what they see. I suppose if they were crafty enough they could figure out how to get to the Admin dashboard which would show them the app tree, but there is a reason we don't allow them ability to build their own reports...

Coyne,

Agree with you and even my user don't have access to build their own report except from the adhoc report that I'm giving them access.
So they never have to choose a master file to build from.

But what I was saying is that within a profile you can limit what user will have access to so you can have "manager" that will access 'MY_MASTER' and other that will access 'MY_MASTER_RESTRICTED' using the same report. And if your users been able to use IA they will only see their "authorized" master file folder.

Martin,
Now I see the light... Thank you.