Group items tagged

For example; certain procedures and workflows will need to be developed (new hire/leaver procedures for example)

are intuitive

Principle of least privilege

object-capability model, any software entity can potentially act as both a subject and object

Access control models used by current systems tend to fall into one of two classes:

Both capability-based and ACL-based models have mechanisms to allow access rights to be granted to all members of a group of subjects (often the group is itself modeled as a subject)

identification and authentication determine who can log on to a system, and the association of users with the software subjects that they are able to control as a result of logging in; authorization determines what a subject can do; accountability identifies what a subject (or all subjects associated with a user) did.

Authorization determines what a subject can do on the system

Authorization

Access control models

categorized as either discretionary or non-discretionary

three most widely recognized models are

Attribute-based access control

Discretionary access control

Discretionary access control (DAC) is a policy determined by the owner of an object. The owner decides who is allowed to access the object and what privileges they have.

Every object in the system has an owner

access policy for an object is determined by its owner

DAC systems, each object's initial owner is the subject that caused it to be created

Mandatory access control

Mandatory access control refers to allowing access to a resource

that allow a given user to access the resource

Management is often simplified (over what can be required) if the information can be protected using

or by implementing sensitivity labels.

Sensitivity labels

A subject's sensitivity label specifies its

level of trust required for access

subject must have a sensitivity level equal to or higher than the requested object

Role-based access control

Role-based access control (RBAC) is an

access policy

Access control

which assumes Shiro's

String format.

Authorization Sequence

what happens inside Shiro whenever an authorization call is made.

invokes any of the Subject hasRole*, checkRole*, isPermitted*, or checkPermission*

securityManager implements the org.apache.shiro.authz.Authorizer interface

delegates to the application's SecurityManager by calling the securityManager's nearly identical respective hasRole*, checkRole*, isPermitted*, or checkPermission* method variants

relays/delegates to its internal org.apache.shiro.authz.Authorizer instance by calling the authorizer's respective hasRole*, checkRole*, isPermitted*, or checkPermission* method

Realm's own respective hasRole*, checkRole*, isPermitted*, or checkPermission* method is called

Authorization Sequence

implies a set of behaviors (i.e. permissions) based on a role name only

named collection of actual permission statements

your realm is what will tell Shiro whether or not roles or permissions exist

Each Realm interaction functions as follows:

key difference with a RolePermissionResolver however is that the input String is a role name, and not a permission string.

Configuring a global RolePermissionResolver

RolePermissionResolver has the ability to represent Permission instances needed by a Realm to perform permission checks.

translate a role name into a concrete set of Permission instances

globalRolePermissionResolver = com.foo.bar.authz.MyPermissionResolver ... securityManager.authorizer.rolePermissionResolver = $globalRolePermissionResolver

shiro.ini