Further testing shows the correct implementation of BusinessObjects should be.

Private Shared Sub AddObjectAuthorizationRules()
            ''More information on these rules can be found here (http://www.devx.com/codemag/Article/40663/1763/page/2).

            Dim canWrite As String() = {"Edit"}
            Dim canRead As String() = {"Read"}
            Dim canDelete AS String = {"Delete"}
            Dim admin As String() = {"Admin"}

            AuthorizationRules.AllowCreate(GetType(CSLA.BusinessObject), canWrite)
            AuthorizationRules.AllowDelete(GetType(CSLA.BusinessObject), canDelete)
            AuthorizationRules.AllowEdit(GetType(CSLA.BusinessObject), canWrite)
            AuthorizationRules.AllowGet(GetType(CSLA.BusinessObject), canRead)
        End Sub

        Protected Overrides Sub AddAuthorizationRules()
            MyBase.AddAuthorizationRules()

            Dim canWrite As String() = {"Edit"}
            Dim canRead As String() = {"Read"}           

            'AuthorizationRules.AllowRead(_identityProperty, canRead)
 End Sub

Collections only need the 
Private Shared Sub AddObjectAuthorizationRules() method security options.

Hello,

Can you please comment on the following :).

1) The implementation is correct for both CSLA 4.x and 3.8 when it comes to the 
method names.
2). The only change needed for AuthoizationRules is to change the modifier from 
protected to private.
3) That the MyBase.AddAuthorizationRules() is 100% needed. From my past 
experience, this throws an exception. (I think it still does in 3.8 but haven't 
looked).

Here is a screen shot of the changes required to all code in the "Entity" 
folder classes.
The AddObjectAuthorizationRules method name is implicitly required to retrieve 
security outside of the business object, for things like menu item enabling.
Example (VB).

SearchToolStripMenuItem.Visible = 
Csla.Security.AuthorizationRules.CanGetObject(GetType(BL.MyVIPObject))

This code would fail if AuthorizationRules.AllowGet wasn't in a method called 
AddObjectAuthorizationRules. If you search the CSLA source code for 
"AddObjectAuthorizationRules" you can see the implicit method name hard coded 
into the source code.

The 3.8 rules override the AddAuthorizationRules BusinessBase method as shown 
here 
(http://www.lhotka.net/cslacvs/viewvc.cgi/core/branches/V3-8-x/cslacs/Csla/Core/
BusinessBase.cs?diff_format=s&revision=4725&view=markup). I believe this is the 
correct behavior. I can see what your saying for the auth rules that are 
invoked via reflection...

Please update this ticket if this isn't the proper implementation.

I have more information around the Authorization rules problem now.

If you want to have field level authorization rules, the current implementation 
causes a compile error if you try and use them. (See screenshot with roll 
over). To confirm this just uncomment some of the existing code generated for 
property Authorization to confirm.

To ensure that you can use Field level authorization rule, you need to 
implement the second pattern. You will notice that the canWrite, canRead and 
admin strings may need organised differently.

You will also notice, once this code is separated, that the intellisense is 
completely different in the two methods (for AuthorizationRules.SPACE). Glad I 
hit this because I didn't realise there was an 
AuthorizationRules.AllowExecute("MethodName",Roles()) option, which I really 
needed for one of my business objects.

Attached is an un-tested patch.