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,

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.

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.

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.