CODEWITHSUNDEEP
c#authorizationclaims-based-identityusabilityfluent-interface
Andrey K.
Andrey K.

Reputation: 735

Claims athorization service API usability

Is the following API of a claims authorization service ok, from the point of view of usability?

/* before UPDATE it was like this:  
var canEdit = Authz.ForNewRequest()
    .WithActionName("edit")
    .WithResourceName("project")
    .WithResourceClaim("DepartmentId","21")
    .CheckAccess(); */

//UPDATE:
var deptId = SomehowGetDepartmentIdAtRuntime(targetProject);
var canEdit = Authz.ForNewRequest()
    .WithActionName("edit")
    .WithResourceName("project")
    .WithResourceClaim("DepartmentId",deptId)
    .CheckAccess();

 if (canEdit) 
 {
     //edit project
 }

And configuration like this:

 var authorizationModel = Authorization.ConfigNamespace.AuthzConfig
     .LoadAuthorizationModelFromXml("authz.xml");

 Authorization.ConfigNamespace.AuthzConfig
     .SetApplicationAuthorization(authorizationModel);

Or custom configuration like this:

 var authzCustomConfig = Authorization.ConfigNamespace.AuthzConfig
     .NewCustomConfiguration()
     .WithCustomClaimBasedFactFunctions(claimBasedFunctions)
     .WithCustomClaimProviders(claimProviders)
     .WithCustomCompositeFactFunctions(compositeFactFunctions)
     .WithCustomObligations(obligations);

 var authorizationModel = Authorization.ConfigNamespace.AuthzConfig
     .LoadAuthorizationModelFromXml("authz.xml", authzCustomConfig);

 Authorization.ConfigNamespace.AuthzConfig
     .SetApplicationAuthorization(authorizationModel);

Basically, the question is about the top part of the iceberg, i.e. how to use the service, but not how to implement or design the inner part. But just in case, here are a couple of general words about this service:

This service gives an answer of true/false for the given authorization request.

Authorization request has information about:

Due to the fact that i use Microsoft.IdentityModel:

Two more things to consider:

That's why custom logic might be injected. Those claimBasedFunctions, claimProviders, compositeFactFunctions, and obligations are the custom logic. But they don't really matter for the question, just some custom confuguration elements, implementations of the interfaces, which are defined in the authorization assembly. The question is not about what they should be, or how they should work. You can think of them as of any interface implementatons that have to be injected.

Thanks!

P.S. this question is off-topic for the Code Review site.

Upvotes: 0

Views: 62

Answers (1)

MvdD
MvdD

Reputation: 23496

If I interpret your description correctly, the following code means: "If you want to edit a project, you need a claim with name DepartmentId that has a value of 21.

 var canEdit = Authz.ForNewRequest()
     .WithActionName("edit")
     .WithResourceName("project")
     .WithResourceClaim("DepartmentId","21")
     .CheckAccess();

 if (canEdit) 
 {
     //edit project
 }

This statement would be at the start of your Edit action in your Project controller in case you were building an MVC application.

If my interpretation is correct, I would advise you to remove the WithActionName and WithResourceName methods. Those things can be retrieved from the context in which this code is executing. Your fluent API is too easy to copy from one method to another and forget to update those strings. I would look at a custom authorize attribute that you attach to an action in which you checks the claims.

UPDATE: I was thinking something like this:

public class ProjectController : ApiController
{
    [HttpPost]
    [MyAuthorize("DepartmentId","21")
    public void Edit(string applicationName)
    {
        // business logic
    }
}

Inside the MyAuthorize attribute implementation you can retrieve the controller- and action names. If the developer using the attribute doesn't have to specify this, he/she can't get it wrong.

Upvotes: 1

Related Questions