You can't reference the same SFS database both at design and run-time (which is what I am attempting to do).
This is exactly right and why you were having trouble.
- 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).
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).
- 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.
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.
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
Sounds like a plan. Let us know if you get stuck and we'll see what we can do to help you.