Ticket #102 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

Fedora Access Control

Reported by: pradeep Assigned to: pradeep
Priority: high Milestone:
Component: topaz Version: 0.5-SNAPSHOT
Keywords: Cc:
Blocking: Blocked By:

Description

Both API-A and API-M should be protected by policies similar to the ones on topaz.

  • If fedora does not have external exposure, we'll configure fedora with no access control.
  • Otherwise external access should be run through a PDP that is configured much the same as topaz

Dependency Graph

Change History

10/20/06 17:01:03 changed by ebrown

  • priority changed from unassigned to high.
  • milestone changed from TBD to november6.

10/20/06 17:36:11 changed by ebrown

  • owner changed from somebody to pradeep.

10/27/06 18:22:57 changed by pradeep

(In [875]) Assign implied permissions also during grant/revoke and cancel-grant/cancel-revoke operations.

Implied permissions are typically permissions required to access services that topaz depends on and may have an external direct exposure. eg. Fedora API-A REST calls will be made by PLoS to retrieve annotation body, article content etc. The permissions that Fedora exposes should mirror the permissions that topaz uses; but without having to have Topaz client applications set the permissions explicitly for them.

Note that the implied permissions apply to the same resource that the client is grant/revoke-ing permissions on. If the resource that the dependent service uses for access verification is different then the XACML policies should be made aware of how to do the resource mapping.

(Addresses #102)

10/27/06 18:30:47 changed by pradeep

(In [876]) Treat secondary resources mapped with the predicate <topaz:implies> as having the same permissions as the primary resource. Currently only the 'ri' model is checked. But other models can be added as needed.

Example: The Fedora PIDs used by articles and annotations can be explicitly set to imply having the same permissions as the corresponding article or annotation.

(See r875. Addresses #102)

10/28/06 00:30:07 changed by pradeep

(In [880]) Couple of mods to r876.

  1. topaz:implies replaced with a more specific topaz:propagate-permissions-to
  2. the propagated permissions are inserted into its own model 'pp'

(Addresses #102)

11/01/06 17:15:27 changed by pradeep

(In [917]) Access check service. Addresses #144,#102.

11/01/06 17:41:58 changed by pradeep

(In [918]) Fedora Authorization replacement module. Executes Fedora policies and in addition enforces Topaz policies on Fedora Objects by doing an access check with Topaz Access service. (See r917. Addresses #102.)

11/01/06 21:47:44 changed by pradeep

(In [922]) Added the fedora-security module (see r918) as a replacement for Fedora's Authorization module in re-packaged Fedora. (Addresses #102)

The checks against Topaz Access Service and the deployment of access service war file into Fedora's tomcat is currently disabled pending seperation of mulgara from Fedora. (InitModels? WebApp? context listener in the access service causes Fedora's Tomcat to hang)

Also API-A access is still left open. Turning that on would break most things.

11/03/06 14:28:45 changed by pradeep

(In [947]) Define implied permissions for Fedora objects used as Annotation and Reply content body. The permissions defined on annotation and reply are propagated to the Fedora PID containing the content body.

This is so that clients (eg. PLoS) need not explicitly define permissions for Fedora PIDs created by Topaz to store annotation and reply content.

(Addresses #102)

11/03/06 15:22:34 changed by pradeep

(In [950]) Extend dc:creator permissions to <topaz:propagated-permission-to> objects also.

(Addresses #102)

11/03/06 23:08:30 changed by ronald

(In [960]) Generate <topaz:propagate-permissions-to> statements for all secondary objects of an article. This relates to [876] and [880], and addresses #102.

11/10/06 18:53:45 changed by pradeep

  • status changed from new to closed.
  • resolution set to fixed.

(In [1027]) Turn on fedora access checks against topaz access service. Closes #102.

Few things to note:

  • Mulgara service must be started before fedora. This is because Topaz acess service is used for fedora access control and the access service depends on Mulgara.
  • The pdp used by fedora for access checks is configured as '_default_' in fedora.fcfg. It can be changed as needed to a pdp name understood by Topaz Access service.
  • The Topaz Access service is available at '/access/services/AccessServicePort' on Fedora's Tomcat (by default at localhost:9090) and can be used by anyone to perform access checks on any configured pdp.
  • Currently fedora's original access control policies are in effect also. But if this turns out to be a problem, can be disabled.

10/29/07 21:12:54 changed by

  • milestone deleted.

Milestone november6 deleted