Hi all -



I have an option in my application to run the SecurityDialog(). The problem I'm having is that the INSERT statements for adding new users, roles, etc. does not seem to know that my application's security project has a security project PK of 1, and therefore the INSERT into SFSUsers should reflect a us_sproj_pk of 1.



Clearly I'm missing something basic... what is it? I looked a my security settings in program.cs and they all look correct, and I know a datasource connection is taking place on startup. When I open the SecurityDialog at runtime (i.e., from the running app) I do see existing security records and can edit them; the problem seems only when adding new ones.



TIA

________________
_____/ Regards,
____/ al

I think you are referring to a design time only field which is used to help in deployment. It isn't needed at all during runtime and isn't set. See this post:



http://forum.strataframe.net/FindPost11664.aspx



Are you having any troubles? i.e. can the newly added users access the app? the correct forms?

Hi Greg -



I had seen that post, and it makes sense to me.



In my case I am having trouble at run-time. If I understand the way RBS works, although it's true that at run-time my app does not need to specify a security project (as basically the security project's key is specified in program.cs), any users or roles that are added at run-time via the SecurityDialog are persisted to the SFSUsers and SFSRoles tables, respectfully. Those tables do have a Foreign Key back to the SFSProjects table (in SFSUsers that would be us_sproj_pk). So for the SecurityDialog to successfully persist the new users or roles record back to the database the FK constraint must be met (i.e., the INSERT must specify a valid security project found in the SFSProjects table).



I can see in the INSERT sent to the backend when I debug my application that the value for SFSUsers.us_sproj_pk is 0; it should be 1 to reflect the only security project found in SFSProjects, which is the project referenced when I setup security in Program.cs.



So the way I see it, the statement that "there's no need for a security project at run-time" is accurate when we talk specifically about the app running on the workstation; once we try to insert new rows into the security database from the SecurityDialog at run-time, the INSERT better send the correct security project PK.



Do I not have this correct?





As I can't add new users via run-time access to the SecurityDialog I can't answer the question about whether they would work. I can say that I took the INSERT SF sent to the backend, changed the 0 to 1 (for the security project ID), ran the INSERT, and was able to then use that new user.



Thanks for your help! I feel there's got to be a setting somewhere that I've not made that is causing the SecurityDialog to default to 0, rather than the correct value for the security project's ID. I just don't know what setting that is.


________________
_____/ Regards,
____/ al

Lets step back a bit. You are typically dealing with two databases when you do security. First, there is the StrataFrame database. This is the one that uses the project ID. Typically you will put all you permsissions in here and likely a very few security users, if any, that are simply the ones you want in the database during a fresh install. You likely might also include roles here too. This allows for easier development. This data must then be deployed to the runtime database.



That is because the SF db isn't ever used at runtime and strictly speaking, isn't actually required. You must deploy the security database tables and optionally, the permissions/roles/base security users configured in the StrataFrame database. This is done most simply via the DDT. You then setup a connection to the database that contains the security tables in the SetDataSources method and you setup security keys/vectors in InitApplication. This database can be your main application database or a specialized security database....but never, ever is the StrataFrame database used at runtime. At runtime the project ID isn't every used: when you call the SecurityDialog at runtime, it just isn't used.



I just want to make sure you have this straight, because if don't have the connection to the runtime security database setup correctly and have your security data deployed, then things can get weird fast.

Greg -



Ok, I think I need to read through the RBS documentation again and see where I'm dropping key points. From what you're saying it sounds like:



- You can't reference the same SFS database both at design and run-time (which is what I am attempting to do).



- You can't have one centralized SFS database that will be used for multiple applications, each with their own distinct users (but possibly sharing the same roles).



- As part of the SFS database deployment any ProjectID columns/values must be set to 0 since that's what the INSERT sends up (or there's structural and/or constraint changes made via the deployment process). I'll be curious how that's handled.



Let me do some homework here and then see about setting up a "run-time" version of the SFS security database and change my SetDataSources to point to it rather than the StrataFrame database as I currently do.



Let me work on this and I'll get back to you...



Thanks.

________________
_____/ Regards,
____/ al

This is exactly right and why you were having trouble.





There are several ways this might be done, most of which are supported without work on your part. The rest required some work. None I can think of are impossible.



Scenario 1: Share same roles permissions between applications but have separate runtime databases. It is definitely possible for several application to share the same security design time project, so they would have the same permissions and roles (at design time, just configure the solution to use the same project in the security editor). You would deploy those roles/permissions to separate runtime security databases (which could be either just part of the main app database or it could be separate security databases). If you are using the DDT, this is easy.



Scenario 2: Share a single security database among multiple applications. It would also be possible, with no effort at all, for you to have a single security database shared by multiple applications, assuming that any differences in access between applications for a user were handled by roles and you don't have any need to manage users separately by application. In other words, if you had a "manager" role, if you assigned a user to that role, they would be a manager in all applications sharing that security database. This is even easier than scenario one, as all you have to do is make sure the security connection points to the same database (you don't have to deploy to multiple security databases).



Scenario 3: The permissions and roles are shared, and you want to share users, but the roles vary by user and application. This requires some work on your part. It is definitely doable though. This would be used if you had a situation were the user was to be given a role of (for example) WarehouseManager with a GRANT action in application A, but would have DENY action in Application B for that same role. In this case you'd need to create some custom tables in the security database to track things like which what applications a user has access to, which roles a user has by application and likely what those applications are. Then you'd have to build a UI to allow for the management of this. I've done something very similar to this and it works great (in my case I needed to alter user security based on which "project" a consultant was working on).





I'd have to look at the source code. Likely it's in the security BOs somewhere, but I'm not sure where. They are in the SF Security project (in the source that comes with SF), in the BusinessObjects folder, if I'm remembering it correctly.





Sounds like a plan. Let us know if you get stuck and we'll see what we can do to help you.