WIF and Authorization based on logic besides roles (also to disable buttons)

Question

We have a Asp.Net-Web-Api server side and wpf (Desktop) client side.

Would a WIF (Windows Identity Foundation) solution fit when:

• we need not only to block access to web-api, but also to pass authorization rights information to the client side in order to disable buttons?
• authorization is based not only on roles. Authorization rights are different according to the type of action, and the type of object to which an action might be applied? For example, an action could be "attach_document" and an object could be say "Project". Or "edit_subentities" for a certain instance of a "SuperEntity"...?
• also authorization would be based on logic applied to both User Attributes and Object Properties. To clarify, we have a tree structure of Organizations. A User belongs to certain Organization, and an Object should be related to a certain Organization. For only some Roles, the rights are dictated by the fact, whether the Object's Organization is a subordinate of the Authenticated User's Organization or not. ...?

Secondarily (not sure if it is correct to ask),

• If WIF fits, it would helpful to know any keywords for googling on how to get started on solution implementation for the logic part
• Are there some better alternatives?

Sorry if the question is too wide or something is not clear or incorrect. It would be helpful to know that the WIF solution is not the best choise in our case before spending time on experimenting. Tanks a lot!

Answer 1

Have a look at ABAC (abac), the attribute-based access control model. It is an updated model which, instead of just looking at roles (RBAC), looks at attributes of:

• the user e.g. role, department, clearance...
• the resource e.g. classification and other attributes
• the action e.g. view, delete, approve
• the context / environment e.g. time of the day, IP address...

ABAC's model provides

• externalized authorization (just like claims-based authorization and RBAC)
• centralized authorization: the authorization logic is maintained in a central component
• policy-based: the authorization logic is expressed as policies that bind together the attributes.

Example:

• A user can view a document if the document's department == the user's department AND the document status == PUBLISHED.

In particular, have a look at XACML (xacml). XACML provides an externalized policy-based authorization solution that you can apply to your .NET applications.

EDIT by question asker (taken from wikipedia):

• PAP - Policy Administration Point - Point which manages access authorization policies
• PDP - Policy Decision Point - Point which evaluates access requests against authorization policies before issuing access decisions
• PEP - Policy Enforcement Point - Point which intercepts user's access request to a resource, makes a decision request to the PDP to obtain the access decision (i.e. access to the resource is approved or rejected), and acts on the received decision
• PIP - Policy Information Point - The system entity that acts as a source of attribute values (i.e. a resource, subject, environment)
• (PRP) - Policy Retrieval Point - Point where the XACML access authorization policies are stored, typically a database or the filesystem.

Answer 2

At the very first approach and thanks to Dominick Baier's contribution, i've come up with a custom ClaimsAuthorizationManager. Seems that it is possible to use WIF as the solution.

• Still don't know whether WIF fits best.
• There's also a question if it is ok to share the authorization logic between client and server side. Haven't thought about that yet.

There's also this post about similar problem.

---

The very first thing, i've come up to is to check access like this:

authorizationManager.CheckAccess("show_subresources", "resource_org_id", "20d55788-bf46-43f0-b6c5-ccb6be687b90");

I'm checking the access imperatively. As for declarative approach with attribute [ClaimsPrincipalPermission(....)] above the method, this seems not to work in our case, because the resource_organization_id is not known until the resource is obtained. The very first approach version of the manager looks like this:

public class AuthorizationManager : ClaimsAuthorizationManager
{
    public const string ActionType = "http://application/claims/authorization/action";
    public const string ResourceType = "http://application/claims/authorization/resource";

    public override bool CheckAccess(AuthorizationContext context)
    {
        //logic

        return false;
    }

    public bool CheckAccess(string action, params string[] resources)
    {
        var principal = Thread.CurrentPrincipal as ClaimsPrincipal;

        var context = CreateAuthorizationContext(
            principal,
            action,
            resources
            );

        return CheckAccess(context);
    }

    private AuthorizationContext CreateAuthorizationContext(ClaimsPrincipal principal, string action, params string[] resources)
    {
        var actionClaims = new Collection<Claim>
        {
            new Claim(ActionType, action)
        };

        var resourceClaims = new Collection<Claim>();

        if (resources != null && resources.Length > 0)
        {
            resources.ToList().ForEach(ar => resourceClaims.Add(new Claim(ResourceType, ar)));
        }

        return new AuthorizationContext(
            principal,
            resourceClaims,
            actionClaims);
    }
}

Note that i'm using the Microsoft.IdentityModel nuget package for .Net 4.0.

The manager should be actualized via the app.config file:

<configuration>
    <configSections>
        <section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    <configSections>

    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>

    <system.identityModel>
        <identityConfiguration>
            <claimsAuthorizationManager type="ClaimsAuthorizationJustATry.AuthorizationManager, ClaimsAuthorizationJustATry"/>
        </identityConfiguration>
    </system.identityModel>
</configuration>

But i did it like this:

FederatedAuthentication.ServiceConfiguration.ClaimsAuthorizationManager = new AuthorizationManager();