package security by studio

[the_tree]

Does anyone know if there is some way to allow access to packages by studio?

So for example, if an admin wanted to let a person have access to certain packages in QS, but different packages in AS… is that type of security possible?

Thank you!

[Darek]

Unfortunately ... no.

[larsonr]

There are some alternatives you could try.  We host the different packages with their appropriate studios in url format.  So the package name is actually a behind the scenes url to the appropriate studio to load that package. 

We then removed the studio links from the top to help prevent them from opening packages under different environments. The only flaw in this logic for your specific case is if they know the URL pattern.  At this point, if it is truly one or the other then you can use your security model to stop them from loading packages in the different studios with this url method. They will get an access denied once the package has loaded.  If they are allowed both QS and AS access, they just need that url pattern to open it in a different studio.

We are still in our early phases but attached is a screen shot of what our users can see.

If I have misunderstood your question, I apologize.

[the_tree]

so would this URL approach apply if I wanted someone to be able to use A & B packages in QS (but not in X & Y), and X & Y packages in RS (but not A & B)?

Thanks!

[larsonr]

From what I have seen from security, you assign a user to a Role that has the tool capabilites.  By order of inheritance if you assign a user to QS and AS, then they in essence have access to both studios.

The part I am trying to understand is why you would want to limit them to one or the other completely.  I understand that some packages behave better (or at all) than others in the different studios.  The URL method is really a first layer restriction method, forcing the user to by default open the package in which studio you designate.

I understand that relational packages do not work in Analysis Studio and that DMR/Cubes become more "alive" in Analysis Studio, but essentially you have the same data in the package despite the analysis tool.

If you have a package with both DMR and Relational, only the DMR section will work in Analysis studio, but both will work in Query Studio.  If it is strictly Relationally modeled, it will create an error in Analysis studio and ask the user to leave.

If you hack the URL string, you could essentially open a package in both studios that the user has access to (then relying on the defined data to handle whether the studio can use it). To prevent users from using any studio, but still run reports, we deny their role the read privelege on the package --> read needs to be re-instated on the reports though.  This will result in a studio denied error if they try to hack the url string.

I have not tried it but you may try ammending security in your develoment environment to see if restricting their QS Role would only allow AS access or not by removing the read privelege to the denied role.  The other interesting piece is that once you create an item in one of the studios it stays in that studio -- the exception is if they have access to Report Studio.  Now they can open it in the formatting studio it started in and Report Studio.

I hope this helps in my explanation of the url method.  This does require an ammendment to the system.xml file --requiring a restart -- to hide the studios in the portal from the users.  Without them and the lack of read permissions on packages, they cannot create intial queries even with a url hack.

If you need more assistance, please send a request to my email address so I may fully understand your requirements and then the post can be made as necessary.  After all, we're here to help.

[larsonr]

After writing that long reply I just noticed you changed your requirement from AS to Report Studio.  I would recommend trying the last part where I talked of restrictive permissions but as I said before I have not tried it in this scenario.  It should not allow them the ability to open it in RS if you deny RS access to the package (I believe that just removing access instead of explicitly denying will work).  Really it all depends on how you set up your security model.

[the_tree]

Thank you for the helpful answer... in referring to denying RS access to the package, do you mean within Framework Manager?

Thank you!

[the_tree]

BTW, I just received this: Cognos enhancement request 462438... looks like a bunch of other folks are looking forward to this enhancement.

[the_tree]

also ERs: 571130 & 496287

[larsonr]

We actually have been managing it from Cognos Connection.