Versions Compared

Old Version 7

changes.mady.by.user Scott Prater

Saved on

compared with

New Version 8

changes.mady.by.user Greg Jansen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The module does not define the set of roles that may be assigned. If you choose to configure a set of supported roles, then the roles assigned via this API will be validated.

Order of operation:

  • Authentication: A user comes into the system.  They are assigned a principalone or more principals:
    • If they authenticate through some authentication gateway, then their principal may be generated from some of the person's attributes;
    • If they don't authenticate, then they may be assigned a default principal (such as "guest").
      • Question:  do we have default principals?  Or only a default role, which is assigned if no principal is available?
  • The principal is then mapped onto one or more roles.  Roles are basically bundles of permissions.
  • The user then makes a request for a given object.  The Fedora PEP intercepts the request, and passes along the roles assigned to the principal to the Fedora PDP.
  • The Fedora PDP will then query the object for the roles it has assigned, compare that to the roles the use has attached to their principal, determine the permissions the user has on the given object, and approve or deny the specific request.
      • ?
    • Principal factory extensions may bring in more principals after authentication, such as groups, from sources like LDAP.
  • (PEP) Query for Assigned Roles on Content: What roles have been assigned?
    • The authorization layer queries the requested repository object(s) for all roles that are assigned to principals.
    • If none are found locally, then it will query each ancestor in turn until role assignments are found.
    • If no role assignments are found in the tree of objects, then a default set of role assignments is used.
  • (PEP) Roles Resolution: What roles does this request have?
    • Assigned roles are compared with the set of principals for the request. Any roles assigned to principals for the request are considered effective.
    • At this point we have the effective access roles for this operation
  • (PEP) Policy Enforcement: Can this role perform the requested operation?
    • The Fedora PEP is an extension point, so enforcement will vary by the chosen implementation.
    • Effective roles will be used to determine if the user is permitted to perform the action on a given object.
  • The PEP will return a response to ModeShape, which will throw an exception to Fedora if access has been denied.
  • Fedora will respond with a 403 if the given REST operation is deniedBased on the decision returned from the PDP, the Fedora PEP will approve or deny the request.

  • The one exception to this process is the admin fedoraAdmin container role.  if a principal has an admin rolethe request has a fedoraAdmin user role (in the container), then no object check is made, and the Fedora PEP automatically approves the request:  checks are made. The PEP is not consulted as admins have permission to do everything.   Objects will never have the admin fedoraAdmin role explicitly assigned to them, since it is a container role and not a content role. (e.g. a tomcat user role)

This module assigns roles to generic security principals, i.e. any class that implements java.security.Principal. Roles are serialized and matched against the principal name, a string property of the principal. All the principals used in your repository environment must have unique names. Other than that, you may use whatever principals you wish. This module does not validate principal names.