Obligations in the OGSA SAML Authorization Service Interface Markus Lorch Virginia Tech & Fermilab OGSA AuthZ Meeting @ GGF12

Existing Functionality Through an (Extended-) AuthorizationDecisionQuery a decision point can return a (Simple-) AuthorizationDecisionStatement which tells the requestor if a specific (set of) actions is permissible for the specified subject on the specified resource.

Obligations Obligations allow for the PDP to convey additional instructions to the PEP on how to allow (or deny) the requested access. More general: obligations can be a set of actions to be executed following a trigger event; the obligation subject can be a number of entities including the access requesting subject and the PEP.

Example Use Case To instruct the PEP with what local UID, primary GID, supplemental GIDs, home directory, and root path, a request should be served with. Obligations can also convey e.g. quota, role based elevated file access and firewall settings - I.e. the actions/instructions specified in the obligations configure and define the execution environment.

What is gained? Obligations in this use-case bridge a mismatch in granularity between policy and access request. I.e. the policy may specify access details such as UID, file access rights, where the request typically specifies “I want to run this executable”. A simple yes/no answer cannot convey the necessary information.

Example Obligation in XACML XACML defines an obligation statement as a set of child attribute statements that define the obligation: <Obligation ObligationId=“OpenScienceGrid:authorization:obligations:UserID“ FulfillOn="Permit"> <AttributeAssignment AttributeId=“OpenScienceGrid:authorization:attributes:UserID“ DataType= "http://www.w3.org/2001/XMLSchema#string"> griduser01 </AttributeAssignment> </Obligation>

Advantages of (re-)using XACML Working towards the SAML/XACML integration – when the current XACML over SAML draft is adopted as a standard we can move to this interface without changes in semantics We can leverage existing implementations that produce/understand this obligation format Several people in the grid community have either expressed plans or have started projects that utilize XACML If other representations of obligations were used then we would have to translate between representations if e.g. XACML policies are used for the PDP

More general specification following PONDER semantics (suggested by D More general specification following PONDER semantics (suggested by D. Chadwick) Ponder names each of the important elements that make up an obligation directly: one or more actions to be performed by the subject the subject that must perform the actions (usually the AEF/PEP, but could be the operation initiator) for each action, the target that the action must be performed on an optional exception action (with target) that must be performed if any of the obligated actions fails

Status I propose the use of XACML through an extension that adds an optional XACML obligation field to the AuthorizationDecisionStatement. This would be a small change that’s in line with the XACML and SAML TC efforts at OASIS. At Fermilab a first prototype implementation of this approach has been produced. D. Chadwick proposes a new, more elaborate ObligatedAuthorizationDecisionStatement format which would hold an ObligationStatement based on the PONDER semantics. This suggestion has been included in the latest draft of the document.