Hello, I've written up some tests and arrived at several possible approaches for https://jira.duraspace.org/browse/FCREPO-787, and wanted to solicit some input about which is preferable.
The Problem: In short, Fedora often cannot checksum external datastreams (type E) with file uris (dsLocation='file://...') because of a XACML prohibition. This is because the the action for retrieving file content is checked as part of the API-M interface, but the security context has no request attributes. This runs afoul of the policies many installations have restricting API-M actions to localhost, or other addresses specified in a policy (and, in fact the default policy). Possible solutions: 1. Change the default XACML policy restricting API-M to allow the file retrieval actions without a client IP. This may be a difficult change to communicate to installations that are overriding that policy. 2. Mimic a request context for the file retrieval action. This requires the least configuration change, but raises the question of what attributes should be included besides client IP. Should there be a fedoraRole, and if so, which? Should it use the internal user information? I think the trajectory of FCREPO development has been towards less use of internal users, but it would allow more elaborate policy specification for retrieval of file resources. 3. Use a different API designator for internal actions. This would address the bug without changes to existing policies, but may obscure what policies must be composed to restrict a given action. Thoughts? Additional solutions? - Ben ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
