Hello Swithun > One question is how I would go about triggering a reevaluation of an > external policy. The script fedora-reload-policies.sh doesn't seem to do > this. Even viewing the updated content of the external datastream in > Fedora doesn't make a difference.
What you may be hitting here is the policy evaluation caching mechanism. Currently there is nothing in place to clear the evaluation results cache when a policy is modified, so the "old" evaluation results can result in stale cache entries rather than evaluation based on modifications to the policy. Fedora-reload-policies operates only on the non-FeSL XACML policies. The work-around currently is to set an environment variable PEP_NOCACHE=true; which disables caching entirely, which is probably a good idea whilst you are modifying policies (you can remove it once you have a stable set). See https://wiki.duraspace.org/display/FCR30/FeSL+Authorization#FeSLAuthorizatio n-Policyevaluationresultscaching. We currently have a JIRA issue raised for this: https://wiki.duraspace.org/display/FCR30/FeSL+Authorization Steve -----Original Message----- From: Swithun Crowe [mailto:c...@st-andrews.ac.uk] Sent: 09 May 2011 10:10 To: Support and info exchange list for Fedora users. Subject: Re: [fcrepo-user] POLICY datastream Hello SB> In FeSL, all XACML policies are stored as datastreams in Fedora SB> objects. So you can either have separate Fedora objects for each SB> policy (with FESLPOLICY datastreams), or you can add a FESLPOLICY SB> datastream to existing objects. Cool. I have something working now. It is an (E)xternal FESLPOLICY in its own Fedora object, and which specifies resources. Other objects which match these resources are then controlled by the policy. One question is how I would go about triggering a reevaluation of an external policy. The script fedora-reload-policies.sh doesn't seem to do this. Even viewing the updated content of the external datastream in Fedora doesn't make a difference. SB> FeSL uses the XACML hierarchical resources profile, so policies can SB> be SB> applied to all members of a collection for example. I didn't realise that this was hierarchical - I thought that /demo:demoObjectCollection/.* was just describing pages below /demo:demoObjectCollection - a URL hierarchy, rather than members of the collection. That makes it a whole lot more interesting. Thanks. If I can use existing RDF statements about membership of collections, then I probably don't need to use another RDF statement just for the policy. Thanks again. Swithun. -- The University of St Andrews is a charity registered in Scotland: SC013532 ---------------------------------------------------------------------------- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
