StrataFrame Forum » StrataFrame Application Framework - V1 » Issues » Security and 1.7.0

Security and 1.7.0

Bill Cunnien — Mon, 03 Aug 2009 13:45:34 GMT

After wrestling all week with the update for SF, I finally posted my application code to the server (click-once deployment). Users today are telling me that they have access to everything in my secured application...all menus and all forms. RBS does not seem to be engaged. Not good.

RE: Security and 1.7.0

Trent L. Taylor — Mon, 03 Aug 2009 13:45:34 GMT

Have Fun!!! :D

RE: Security and 1.7.0

Bill Cunnien — Mon, 03 Aug 2009 13:42:59 GMT

I don't mean to point fingers at the update. My problem resided in the assembly nightmare (points at the GAC). So many goofy things were going on ever since the attempts to update that all I am doing is using that as a checkpoint. I was hoping there was some kind of security settings that may have been reset because of mismatching assemblies. In a different thread, I discovered that form control properties were reset because of assembly problems. I was thinking this was a similar issue.

It is working. I can actually start my vacation, now. :w00t:

RE: Security and 1.7.0

Trent L. Taylor — Mon, 03 Aug 2009 13:30:35 GMT

[quote]The code that I added sets the default action. The application works, now. The code I commented out *did* work before the update.[/quote]

The code that you set is what should have been set all along. I know that everybody like pointing fingers at updates (me included), but this hasn't changed since the very beginning of the RBS of SF. At any rate, glad you got it going.

RE: Security and 1.7.0

Edhy Rijo — Mon, 03 Aug 2009 13:21:44 GMT

Hi Bill,

This is what I have in my AppMain.vb InitApplication()
[codesnippet]
'-- Set the default actions for security enabled objects within the application
SecurityBasics.DefaultPermissionInfo = New PermissionInfo(PermissionAction.Deny, _
"Access Denied.", DeniedActions.Message)
SecurityBasics.DefaultPermissionAction = PermissionAction.Deny
SecurityBasics.DefaultBlockedMsg = "Access Denied."
'SecurityBasics.DefaultBlockedMsgKey = "AccessDeniedKey"
SecurityBasics.BlockedReplacementCharacter = "*"c
SecurityBasics.BlockedReplacementRegex = "[A-Za-z0-9@]"
[/codesnippet]

If this is an old application, try creating a new SF project and compare the code in the program.cs with yours, probably something may have changed before.

RE: Security and 1.7.0

Bill Cunnien — Mon, 03 Aug 2009 13:10:38 GMT

Here is what I did in the InitApplication method:

SecurityBasics.DefaultPermissionAction = PermissionAction.Deny;
//SecurityBasics.DefaultPermissionInfo = new PermissionInfo(PermissionAction.Deny);

The code that I added sets the default action. The application works, now. The code I commented out *did* work before the update.

Why this new code works? I dunno. :blink:

RE: Security and 1.7.0

Bill Cunnien — Mon, 03 Aug 2009 12:51:50 GMT

Each role that I cycle through for the SF user after authenticating is coming back as Granted, although only one, Accounting, has been allowed for that user. All roles should be denied expect the accounting role/permission. Why would that be happening?

RE: Security and 1.7.0

Bill Cunnien — Mon, 03 Aug 2009 11:55:47 GMT

An SF user using standard authentication has full access. The user has only accounting access. For some reason, the permissions are not being read properly. It is as if the default for all roles/permissions is 'granted'. I will write something to review the user's privileges.

RE: Security and 1.7.0

Trent L. Taylor — Mon, 03 Aug 2009 09:54:00 GMT

Well, the first thing I would do is to log in with an SF user using standard authentication to see if you have the same results. Next, I would take a single user, verify the permissions, etc. and immediately after logging in, I would write a little test and verify that the user's permissions were granted and denied appropriately.

If this works, then I would back up one step and try it for an AD authentication and go through the same process.

So let's work from the most granular level first by looking at permissions for a particular user to ensure that they are pulled (and stored) int he DB properly.

RE: Security and 1.7.0

Bill Cunnien — Mon, 03 Aug 2009 09:33:06 GMT

Let's say I had a problem with assemblies not matching (and, I did). In what way could the security subsystem be changed so that it is not actually working? When my assemblies were messed up, some controls were overwritten. Perhaps, something was changed in security somewhere. Is there any place that I could look to determine why the security is not working. The app works fine...it is as if everyone has access to everything despite the fact that I have this code in my program.cs:

[codesnippet]SecurityBasics.DefaultPermissionInfo = new PermissionInfo(PermissionAction.Deny);[/codesnippet]

RE: Security and 1.7.0

Trent L. Taylor — Mon, 03 Aug 2009 08:25:53 GMT

Bill,

I don't think that this one is on us. We have been doing this for quite some time now and we too have rolled this out into the field. I think that there is something else going on within your code. If you are using AD for authentication, this definitely cannot be SF as we don't do the authentication at this point. This is all pass-through. The only thing handled by SF when authenticating off of AD is that once you authenticate, then we use the user name to associated permissions, etc. to the user.

More information is definitely needed on this one.

RE: Security and 1.7.0

Bill Cunnien — Sun, 02 Aug 2009 12:08:08 GMT

I am integrating AD with RBS in SF. Since I am both a network admin as well as set as a system admin in the RBS, I am unable to tell when debugging. It was brought to my attention after I had released the update. Never expected a problem with security. And, it is a sticky one, too.

RE: Security and 1.7.0

Aaron Young — Sun, 02 Aug 2009 07:35:31 GMT

Bill, I haven't rolled out 1.70 to my customers but the security is working when I run the application on my development PC. Is the security failing on your development system?