CSLA 3.6 B2 - Security in static AuthorizationRules methods

CSLA 3.6 B2 - Security in static AuthorizationRules methods

Old forum URL: forums.lhotka.net/forums/t/5708.aspx


Patrick posted on Thursday, October 30, 2008

Hi,

because AuthorizationRules.CanEditObject is public the following is possible:

Current user is in role "Artist":

Csla.Security.AuthorizationRules.CanEditObject(typeof(Library.Edges.EdgeBase)) evaluates to false

call this from UI code:
Csla.Security.AuthorizationRules.AllowEdit(typeof(Library.Edges.EdgeBase), new string[] { "Me", "Myself", "I", "Artist" });

then test again:
Csla.Security.AuthorizationRules.CanEditObject(typeof(Library.Edges.EdgeBase)) evaluates to true now.

Thanks,
Patrick

RockfordLhotka replied on Thursday, October 30, 2008

That is true, and is a possibility of which I'm aware. I don't directly consider it a bug however, for two reasons.

First, this enables a scenario where you have a "security loader" object that loads all the per-type rules for your business layer all at once (probably data driven). That's very valuable.

Second, it is not clear how I'd prevent this in any case. At least not without seriously complicating the process of calling AllowEdit(), etc. The only real solution would involve making those methods internal to CSLA, and then having all the CSLA base classes expose a protected instance of some class that could invoke the internal methods. Very messy - and this would preclude the security loader concept.

Patrick replied on Thursday, October 30, 2008

RockfordLhotka:
That is true, and is a possibility of which I'm aware. I don't directly consider it a bug however, for two reasons.

Hi Rocky,

that's true if you are aware of it it's not really a bug :)

RockfordLhotka:
First, this enables a scenario where you have a "security loader" object that loads all the per-type rules for your business layer all at once (probably data driven). That's very valuable.

Second, it is not clear how I'd prevent this in any case. At least not without seriously complicating the process of calling AllowEdit(), etc. The only real solution would involve making those methods internal to CSLA, and then having all the CSLA base classes expose a protected instance of some class that could invoke the internal methods. Very messy - and this would preclude the security loader concept.

Good point.

One solution might be to make a private property bool _permissionsSealed.

After setting permissionsSealed = true a call to this would throw an exception:

Csla.Security.AuthorizationRules.AllowEdit(typeof(Library.Edges.EdgeBase), new string[] { "Me", "Myself", "I", "Artist" });

throws excpetion

Business base could automatically set permissionsSealed after calling AddObjectAuthorizationRules()

So a user loading business rules from the outside would just need to make sure to do it in the very beginning before AddObjectAuthorizationRules() is called.

All the best,
Patrick

Copyright (c) Marimer LLC