ALFA Attributes

ALFA policies are made up of attributes. Attributes describe the user attempting the access, the action being attempted, and the object being accessed. Attributes are made up of an identifier, category, and datatype.

ALFA lets you define any number of attributes in a dedicated attribute dictionary. The dictionary can be inlined inside the same ALFA files as the policies or stored in a separate file. The following table provides sample attributes.

Name Description ALFA Declaration
com.acme.user.name The user's name e.g. Alice. 

namespace com.acme.user{
    attribute name{
        category = subjectCat
        type = string
        id = "com.acme.user.name"
    }
}

Who, what, where, when, why, and how - Defining authorization attributes

When you are used to RBAC, it's tempting to try and create roles and entitlements. This leads to artificial roles as well as role explosion. For instance, in a banking scenario where a teller can only see a customer's data if they are in the same branch, it's tempting to create teller_branch1 as a role.

Instead, though, think of the basic building blocks of your requirement. If the statement is A teller can view a customer's profile if they are in the same branch. then highlight the key words i.e.

  • teller: role, of type string. It describes the user.
  • view: action, of type string. It describes the attempted or intended action.
  • customer profile: objectType, of type string. It describes the type of item the teller is trying to access.

What about same branch? That's an attribute of a relationship. What we're really saying is the user's branch is equal to the customer's branch. This gives us two new attributes to contend with:

  • user's branch: branch, of type string (or possibly an integer if using numerical location codes). It describes what location the user belongs to. It could be multi-valued (i.e. the user could work in multiple branches).
  • customer's branch: branch, of type string. It describes the branch the customer is assigned to.

Other attributes include time of day, a user's IP, etc. For instance, we could rework our requirement and add contextual constraints e.g. A teller can view a customer's profile if they are in the same branch. They can only access the data between 9am and 5pm from a company computer/IP.. This introduces time and IP address as new attributes

Much like policies, attributes are defined inside namespaces in ALFA. Namespaces are a means to organize policies and attributes. A namespace is very much like a C# namespace or a Java package. It's a series of period-separated names (alphanumerical) e.g. com.acme.example.

An attribute definition contains a field called id. The value of that field can be anything but try to keep it logical and aligned to the attribute's name and the namespace it belongs to.

Attribute Definition File (ALFA)

      
namespace guide.alfa.bank{
    namespace employee{
        attribute jobTitle{
            category = subjectCat
            type = string
            id = "guide.alfa.bank.employee.jobTitle"
        }
        attribute branch{
            category = subjectCat
            type = string
            id = "guide.alfa.bank.employee.branch"
        }
    }
    namespace account{
        attribute branch{
            category = resourceCat
            type = string
            id = "guide.alfa.bank.account.branch"
        }
    }

    attribute objectType{
        category = resourceCat
        type = string
        id = "guide.alfa.bank.objectType"
    }   

    attribute actionId{
        category = actionCat
        type = string
        id = "guide.alfa.bank.actionId"
    }   

}

Best Practices

  • Keep your ALFA identifier in sync with the identifier in the definition.
  • Use camel casing e.g. userLocation.
  • Don't indicate the type of the attribute in the name.
    • Bad:com.acme.user.clearanceCodeInteger
    • Good:com.acme.user.clearanceCode
  • Use complete names; avoid abbreviations unless well-known and widely used e.g. ZIP code.
    • Bad:com.acme.user.isGldCstr
    • Good:com.acme.user.isGoldCustomer