Hi all. 

As we look to better manage multiple, technologically-dissimilar applications in order to ease application management tasks, the topic of security has surfaced. Does anyone have thoughts on whether the StrataFrame Role-Based Security (RBS) model and database could be leveraged to become a single user authentication/permissioning system used by departmental web and windows applications, both SF and non-SF based? 

This is very early in the brainstorming phase, but the idea would be that given our usually-similar user roles across multiple applications, we'd setup a StrataFrame security database and use it for all/most apps to determine a given user's role and permissions. As an example assume that one of our users is considered an "admin" and can perform similar "admin-like" duties across a suite of applications. We'd like those apps to all hit against the SF RBS database to determine what permission "keys" the "admin" has. 

Hopefully the above is succinct, yet sufficiently clear enough to make sense. Any thoughts are appreciated. Obviously this is outside the scope of what our friends in Texas had in mind, but...

________________
_____/ Regards,
____/ al

The sweet thing about the RBS is that you can extend it if you need to. The first thing I had to do with it was to extend it to support varying levels of access based on which client a consultant was working with. Consultants could be assigned to work on various client projects, with different roles. Essentially I had to add some extra tables within the security realm, manage the roles that were assigned via project, and then assign those roles dynamically when a they logged into specific projects.  While this is likely very different from what you need, I'm just giving an example of how it has been extended.

In your case, it sounds like the following would be necessary:

1. Permission management. You'll just need to think about permissions, which are common, which are specific to an app. You could use the group feature to organize things. 
2. You'll need to have a separate database just for security.  If you are using security with current SF apps and the security tables are in the app db, you'll have to move the data to the common db and change the connection string and key for the security tables. Not too bad.
3. You'll need to create something that the none-SF based apps can access. First thought would be a web service, but it could be an ActiveX control or whatever works (or you might need several of these). I.e. you'll some way for your non-SF apps to authenticate and to determine permissions.  This likely won't be too hard.
4. You'll need to update the Non-SF apps to use the above service. This will be some work, depending on the app and your security requirements. If you have simple security (i.e. security simply determines if the user can access app or not or if they are admin), then this won't be bad. However, if you need to check permissions for every form or do field level checks, then this could be....er...exciting.  I'd think that if the app is .NET based at all, you'd just rewire it use the RBS.

I'd be careful reusing permissions across apps (with exception of admin rights). Because you'll need to alter the apps to use the permissions, if you have a common permission that suddenly isn't common, you'll need to update the app to use a new permission. I.e. If you have a common Edit permission that allows a user to change data in all apps, you'll need to modify all you're apps to use this permission.  Later, if App X needs to limit who can edit in that app (i.e. not every one with Edit permission should be editing App X), you'll need to setup a new permission (AppXEditor) and then modify App X to use the new permission.  You'll have to balance the cost of administering all the separate sets of permissions with the cost of changing apps later.

Hope that helps!

Greg - 

Definitely help. Thanks! Sounds in line with what I was expecting, including the concern over reusing permissions across multiple apps. Last time I worked on RBS (to setup the initial implementation of a StrataFrame Role-Based Security (RBS) enabled app), I did decide to go with a separate security database for the reasons you gave. Also decided that permissions would be app-specific, but named to facilitate security management. So, I'd have things like

Edit - App A

Edit - App B

ReadOnly - App A

ReadOnly - App x

Appreciate the quick reply! 

________________
_____/ Regards,
____/ al

It looks like you are in good shape.  The hard part will likely be getting non-SF apps to work with it, but that's doable...and if they are .NET apps....then adding SF security is much easier.

Hi Alex

I would have do it the other way around, Applications, then permissions to encapsulate all permissions per applications, probably that would make it easier to maintenance the security.

App A
  ->Permission Name
       -> Add
       -> Edit
       -> Delete

App B
  ->Permission Name
       -> Add
       -> Edit
       -> Delete

Edhy Rijo