Asynchronous Authorization Rules with Blazor and AuthorizeView Policies

[mtavares628]

My question is two-fold:

1. Is there a way to make an AuthorizationRule Async like BusinessRuleAsync?
2. Is it possible to Adjust CslaPolicy so that is would support the other overloads of BusinessRules.HasPermission as well?

Here's the context for these questions. I have a project that I've been maintaining since the v3.x days where we created CanGetObject, CanAddObject, CanEditObject, etc. When 4.x was first introduced, there wasn't really an option to pass a dynamic parameter into the rules, and I needed the ability to hit the database to check the ID of the object to see if the user has individual permissions to view that object. Basically, a user needed to have a certain role, but also have specific permission to view a client record. Because 4.x didn't have that (or I couldn't see how to do it) I just continued to use the CanGetObject function that I was using for 3.x. So here's an example where I've used the 4.x AddObjectAuthorization with the Roles, and then call that in a CanGetObject function that I would then call specifically from my UI:

        protected static void AddObjectAuthorizationRules()
        {
            BusinessRules.AddRule(typeof(Client), new IsInRole(AuthorizationActions.CreateObject, "CreateClients"));
            BusinessRules.AddRule(typeof(Client), new IsInRole(AuthorizationActions.GetObject, "ViewClientRecords"));
            BusinessRules.AddRule(typeof(Client), new IsInRole(AuthorizationActions.EditObject, "EditClientRecords"));
            BusinessRules.AddRule(typeof(Client), new IsInRole(AuthorizationActions.DeleteObject, "DeleteClients"));
        }

        /// <summary>
        /// Determines whether the current user has rights to retrieve the specific client object
        /// </summary>
        public static bool CanGetObject(int clientID)
        {
            var result = default(bool);
            if (BusinessRules.HasPermission(AuthorizationActions.GetObject, typeof(Client)))
            {
                HasPermissionForClientCommand cmd = DataPortal.Create<HasPermissionForClientCommand>(clientID, AccessPermissions.ReadAccess);
                cmd = DataPortal.Execute(cmd);
                result = cmd.HasPermission;
            }

            return result;
        }

Since then, the ability to add the criteria object as an overload of the HasPermission method in 5.5.2 #1226 has opened up the ability for me to start using the built in authorization system with my own custom AuthorizationRule that would hit the DB. However, with Blazor, I now have to run my Command Object that hits the DB asynchronously, but I don't see an AuthorizationRuleAsync like I do a BusinessRuleAsync.

So, hence my first question is there a way to make an asynchronous authorization rule?

Right now my workaround is to keep using my own method converted to async:

        public static async Task<bool> CanGetObjectAsync(int clientID)
        {
            var result = default(bool);
            if (BusinessRules.HasPermission(AuthorizationActions.GetObject, typeof(Client)))
            {
                HasPermissionForClientCommand cmd = await DataPortal.CreateAsync<HasPermissionForClientCommand>(clientID, AccessPermissions.ReadAccess);
                cmd = await DataPortal.ExecuteAsync(cmd);
                result = cmd.HasPermission;
            }

            return result;
        }

But that leads to my second question in wanting to use the AuthorizeView in Blazor with the CslaPolicy. I obviously can't do it with my work around, but assuming there was the option for an asynchronous auth rule, is there a way to add the ability to call the other overloads of HasPermission with the CslaPolicy? Right now GetPolicy only takes the action and the object type. It would be great if it could also take the criteria objects or the business object itself (in the case of editing).

[rockfordlhotka]

Interesting question.

My first thought is that it probably isn't possible, because we don't control how Blazor interacts with the Authorize attribute, and I very much doubt they invoke the attribute asynchronously. Therefore, the when the attribute is invoked, it must provide an immediate result, before any async task would complete.

That is something you could test, or look at the Blazor code to confirm.

There's no doubt that the per-type rules are not intended to act on instance data as you describe. The scope of the CSLA feature is purely to operate on the business domain type plus any ambient context (like the user identity, ClientContext, etc.).

What you want to do is perfectly reasonable however, so it seems worth thinking through how to cleanly solve your scenario: once some information is known about the domain instance to be created/fetched/updated/deleted/executed, what is the best way to abstract a "HasPermission" question that includes ambient context (user identity, ClientContext) and also this potentially limited information about the domain instance.

I just reviewing this between meetings, so don't have an answer offhand. It is worth thinking about further for sure.

[mtavares628]

Hi @rockfordlhotka,

So, I took a closer look at things, and I'm not all that well versed in the authorization attribute, but it looks like the AuthorizationAttribute doesn't need to be asynchronous. It's the authorization handler that would do the asynchronous rule check, and the method for doing that is already asynchronous. It seems like the trick would be how to create the policy string so that it would include the ambient context to be split out into the CslaPermissionRequirement with the correct data types. So right now you are concatenating the Action and the BO type in the policy string with a pipe delimiter. What if you were to tack on the additional parameters with their value and data type with a separate delimiter for each pair? So the permission would look like:

@attribute [HasPermission(AuthorizationActions.GetObject, typeof(Client), clientID)]

And in the GetPolicy method of the CslaPolicy you could have:

        public static string GetPolicy(Rules.AuthorizationActions action, Type objectType, params object[] args)
        {
            var actionName = action.ToString();
            var typeName = objectType.AssemblyQualifiedName;
            string arguments = String.Empty;
            foreach (object item in args)
            {
                arguments += $"|{item.ToString()}:{item.GetType().AssemblyQualifiedName}";
            }

            return $"{PolicyPrefix}{actionName}|{typeName}{arguments}";
        }

CslaPermission would also need to have an object array property as well, and then the TryGetPermissionRequirement can parse the string with the necessary types. I'm not 100% sure how to do this off the top of my head, since I'm not that well versed in reflection but something like this:

        public static bool TryGetPermissionRequirement(string policy, out CslaPermissionRequirement requirement)
        {
            if (policy.StartsWith(PolicyPrefix))
            {
                var parts = policy.Substring(PolicyPrefix.Length).Split('|');
                var action = (Rules.AuthorizationActions)Enum.Parse(typeof(Rules.AuthorizationActions), parts[0]);
                var type = Type.GetType(parts[1]);
                List<object> argList = new List<object>();

                if (parts.Length > 2)
                {
                    for (int i = 2; i < parts.Length; i++)
                    {
                        var arg = parts[i].Split(':');
                        var argtype = Type.GetType(arg[1]);
                        if (argtype != null)
                        {
                            var obj = Activator.CreateInstance(argtype);
                            // Set the value of obj to arg[0], not sure how to do this correctly
                            argList.Add(obj);
                        }
                    
                    }
                }


                requirement = new CslaPermissionRequirement(action, type, argList.ToArray());
                return true;
            }
            else
            {
                requirement = null;
                return false;
            }
        }

Maybe this isn't the best implementation, but it's all that I can think of to pass the array of arguments using the policy string. I'm also not sure how to implement the AuthorizationRuleAsync class required for me to run the auth rule itself asynchronously.

Let me know if I'm completely off base here. Thanks.

[rockfordlhotka]

Good analysis, this makes me more hopeful that such a thing can work.

From the CSLA perspective, we'd have to start by adding an IAuthorizationRuleAsync interface, similar to the IBusinessRuleAsync approach, and then enhance the rules engine to honor this new interface.

Then we can build out to support such async authz rules elsewhere.

[rockfordlhotka]

The other complication I can anticipate, is that the data portal invokes per-type authz rules. If you do a sync data portal call, there's no reliable way to await an async rule (due to synchronization context issues in some UI frameworks). So if you have any async authz rules, you could only use the async data portal.

I'm ok with that limitation, but don't know how to enforce it in a way that tells people that they are doing something bad. They'd find out when their app locks up due to a deadlock. Which seems impolite.

So this needs to be thought through and figured out.

[mtavares628]

I have 2 thoughts here.

1. What about allowing for 2 per-type authz rules for each action type? One for sync and optionally one for async. The sync dataportal would only look at the sync auth rules, and the async would look for the async rule first, but fall back to the sync rule if one doesn't exist.

2. Could an analyzer be created to warn that if an async auth rule exists, then only the async dataportal can be used when making the data portal call on that BO?

I throw out both of those suggestions having never coded an analyzer, and never really looking at your auth and data portal engines, so these may both be bad ideas.

In all honesty, the need for an async auth rule is only because of Blazor, and we are forced to make all of the data portal calls async anyway.

[rockfordlhotka]

Added to backlog: #2801

[rockfordlhotka]

Right now GetPolicy only takes the action and the object type. It would be great if it could also take the criteria objects or the business object itself (in the case of editing).

I don't think this is possible, because iirc, the aspnetcore policy scheme is really just a string. So I don't think there's a way to pass complex data like an object reference.

[mtavares628]

You are correct that it is just a string. I somewhat addressed this above at least for primitive types. But couldn't it be extended to complex types by serializing them and then de-serializing them when parsing the policy string? Maybe I'm wrong. I didn't completely flesh it out above because I wasn't sure what reflection calls were needed. My suggestion was to pass both the type of the criteria object as a string representation concatenated with some delimiter followed by the serialized object. Even if it's a bad idea for complex types, I think it would still be valuable for the primitives.