Manage Authorization
From HiWiki
PING Discovery: Pilot implementasjon og utforskning av PING -> Security -> Authorization -> Manage Authorization
Authorization can be managed in three ways:
- In each action responders authorize method
- In each action responders xml policy file (e.g. addPolicy.xml)
- In each Ping records access policy document
Contents |
The responders authorize method (for the developer)
The easiest way we can change the authorization is to modify the method authorize(..) in each action responder class. Potential new implementations of authorization should be called here. Any changes here is done by the developer, and a recompilation and redeployment of the servlet is necessary for changes to take effect.
The responders xml policy file (for the server administrator)
When a user wishes to perform an action the first step in the authorization is according to policies defined for each action responder. These rules, or policy sets, are loaded when the servlet is beeing initialized. Each action has its own policy set with policies defined in a XACML file.
XACML, eXtensible Access Control Markup Language, is an XML based language for access control. In PING it is used to make rules taht apply to the whole PING server. These rules is located in the classes folder in the WEB-INF folder in Tomcat, and are read in by the servlet at initialization. They are then used by the PDP (Policy Decision Point) to deny or permit an request. More on XACML and its function here, and in the OASIS XACML standard document.
The policy xml file consists of a top-level PolicySet and a Policy, each with a Target that have Subjects, Resources and Actions that define who and what the Policy relate to. The Policy have a set of Rules that define the desired Effect of the Rule. To deciede the effect the Rule, Attributes are evaluated with the help of different Functions.
An example of a policy is given below. This is a policy rule that is used when a medical document is added.
<PolicySet
xmlns="urn:oasis:names:tc:xacml:1.0:policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
PolicySetId="urn:PolicySetId"
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:ordered-deny-overrides">
<Description>
This PolicySet applies to all subject attempting to perform an
AddDocument action through the DefaultAddDocumentActionResponder.
The Policies included in the set should be written to evaluate DENY if the
action is not allowed. The absence of an applicable policy or a policy
that evaluates to PERMIT will cause the responder to delegate the decision
to the policies of the record that the action is being taken on.
</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">urn:org:chip:ping:action:addDocument</AttributeValue>
<ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string"
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Policy
xmlns="urn:oasis:names:tc:xacml:1.0:policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy
cs-xacml-schema-policy-01.xsd"
PolicyId="GeneratedPolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:ordered-deny-overrides">
<Description>
This Policy applies to all subjects attempting to perform an
AddDocument action where the document that they are adding is
classified as a medical document. This policy is for use with the
DefaultAddDocumentActionResponder.
The Policy contains a single rule that specifies that a subject that
does not have a role attribute of "provider" is not allowed to add
documents classified as a medical document.
</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:regexp-string-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">urn:org:chip:ping:document:classification:medical</AttributeValue>
<ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string"
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Rule RuleId="DenyNotProvider" Effect="Deny">
<Description>
This rule denies anyone that does not have a role set to "provider"
</Description>
<Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:not">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string"
AttributeId="urn:org:chip:ping:attribute:role"/>
</Apply>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">provider</AttributeValue>
</Apply>
</Condition>
</Rule>
</Policy>
</PolicySet>
A summary of the example xml policy files:
addPolicy.xml:
- Applicable to type of action: urn:org:chip:ping:action:addDocument
- Document type: urn:org:chip:ping:document:classification:medical
- Allowed for: urn:org:chip:ping:attribute:role = provider
authPolicy.xml:
- Applicable to type of action: urn:org:chip:ping:action:authenticate
- Document type:
- Allowed for: urn:oasis:names:tc:xacml:1.0:subject:subject-id = ping.chip.org
createPolicy.xml:
- Applicable to type of action: urn:org:chip:ping:action:create
- Document type:
- Allowed for: urn:org:chip:ping:attribute:role = administrator
updatePolicy.xml:
- Applicable to type of action: urn:org:chip:ping:action:update
- Document type: urn:org:chip:ping:document:classification:medical*
- Allowed for: urn:org:chip:ping:attribute:role = provider
Adding, deleting or modifying these xml-files is easy, and one does not have to change the source code for it to take affect. However a restart of the server is required for the changes to take affect. It is therefore easy for a server administrator to manage.
The records access policy document (for the user)
The access policy document is one of the three documents that are essential for the record as described in PING record. This document controls the access to the record with the use of a policy set. This policy set contains a set of individual policies (ironiclly enough). Each policy define a rule for access based on a list of users, a list of resources, a list of actions, and finally an effect. The list of users is simply defining what users this rule apply to, the resources to the kind of document, the actions on the kind of action to be performed, and the effect is either to deny or permit the actions.
To acctually change or add policies is similar to updating any other document in the record. First you will have to find the document you want to update and get the document index. By creating a new document on the client and then extracting only the document version you can send the document index and the new version to the server.
An example of how to make a access policy document is shown next:
// make a list of which ping users the rule apply to
List subjectIds = new ArrayList();
// add all the users like this, where pingId is on the form user@ping.chip.org
subjectIds.add(pingId);
// make a list of the resources the policy apply to
List resourceIds = new ArrayList();
// add all resources like this, this is a credentials document
resourceIds.add(urn:org:chip:ping:document:classification:credentials);
// make a list of the actions the policy apply to
List actionIds = new ArrayList();
// add all actions like this, the actions can be found in the different action responders authorize mehtod.
actionIds.add(PingTalkUrns.ADD_DOCUMENT_ACTION)
// generate the policy with an effect
Policy policy = DefaultPolicyGenerator.generatePolicy(subjectIds, resourcesIds, actionIds, Result.DECISION_PERMIT);
// add more policies here
// make a policy list
List policies = new ArrayList();
policies.add(policy);
// genereate the policy set
PolicySet policySet = new PolicySet(new URI("RecordPolicySet"), new DenyOverridesPolicyAlg(), new Target(null, null, null),
policies);
// add the access policy document to the record
record.getPingDocument().add(DefaultAccessPolicyDocumentGenerator.generateAccessPolicyDocument(authorId, authorName, authorRole,
policySet));
This way the access to a record can be adjusted as the owner pleases. Modifying of these rules is done real-time in the application, and is therefore intended to give the user the desired control over his/her record.
You can specify a policy for a single document, but not for each document version. To seperate between several documents of the same classification, you use the document index. Example:
If you look at the DefaultReadDocumentActionResponder.process() method, you can see that the resourceId for authorization is: DocumentClassification + “[“ + documentIndex + “]”. Eg. A document classified as an allergy document with the index “dafadsf” would have a resourceId of “urn:org:chip:ping:document:classification:allergy[dafadsf]”.
