How It Works

How does Fabric.Authorization work?

Fabric.Authorization is a set of APIs that allows applications to associate groups, roles, and permissions with each other.

Main Fabric.Authorization Components

Here are the major components of Fabric Authorization:

• Client: An application that has roles and permissions to be managed within fabric authorization.
• SecurableItem: A collection of entities or resources that require additional security and can have their own associated roles and permissions within a client.
• Role: A position or name assigned to groups of individuals that share the same functions and permissions
• Permission: A function that defines what actions or access are allowed for a user in an application
• Groups: A collection of individual users that share the same assignment to roles and permissions. A group can either be an existing group on identity provider or a custom group created within fabric authorization. The type of group is defined with groupSource.
• User: An individual that will log into an application. Fabric authorization does not create user and can only work with users that already exist on identity provider.

Fabric.Authorization Setup

Here is a sample set up for fabric authorization to illustrate the relationships among the components:

1. A client must first be set up and securableItems defined, if applicable.

   In this example, a client named My App is created.

2. Next, roles and permissions should be defined within the client. Roles and permissions that live at the app-level should be defined with app as the grain and the app name as the top level securableItem. It is possible to define roles and permission at a more granular securableItem level if desired.

   In this example, there is an Editor role set up at the MyApp level with a permission, EditPatient, also at the same MyApp level.

3. Groups from identity provider and custom groups should be defined in fabric.authorization and user added (only) for custom groups.

   In this example, a custom Group, DemoGroup, is created with two users on Windows AD.

4. Associate groups to the appropriate roles.

   In this example, the DemoGroup is associated with the editor role for this client, so when Alice.Kelly or Bob.Smith logs in to MyApp, they will inherit the Editor Role with EditPatient permission. The app will see the user has EditPatient permission and can determine the correct resources or actions for user to access/act on.

Resources

Here is an overview video on fabric.authorization.