SAML2XACML2 AuthZ Query Interface Obligations, ObligationIdHandlers, AuthZ

1
SAML-2-XACML-2 AuthZ Query InterfaceObligations,
ObligationId-Handlers, AuthZValidation,
Standardizing Attributes

• OGF20 _at_ Manchester, UK
• OGSA-AuthZ-WG, Monday, May 7, 2007
• Frank Siebenlist - franks_at_mcs.anl.gov

2
OSG/EGEE/Globus Development Effort

• Standardize AuthZ Query Interface for OGFs
  PRIMA/GUMS/SAZ
• Migration of obligation-extended SAML-1.1 to
  XACML-2
• Use XACML-2 AuthZ Query for SAZ-blacklist-check
• Standardize AuthZ Query Interface for next-gen
  LCMAPS/LCAS service implementation
• XACML-2 Query Interface
• Goal is to make PRIMA/GUMS/SAZ and LCMAPS/LCAS
  plug-compatible on service interface level
• Standardize AuthZ-ticket for GAAA-AuthZ Toolkit
• XACML-2 AuthZ Query Result as (possible)
  ticket/token
• Allows for sophisticated authZ result-caching
• Allow for optional certificate/assertion
  validation as part of AuthZ
• Pass unvalidated certs as attributes through
  AuthZ interface

3
GT-XACML Service Interface

• Port type generated
• Uses XACML SAML 2.0 profile
• Services will need to implement port type
• Sample Authorization Service provided
• Returns a permit for any non-anonymous access
  that is not on a configured list

4
GTs XACML-PDP Authorization Callout

• PDP that can be configured to talk to any XACML
  Authorization Service
• Authorization service endpoint should be
  configured
• If a permit is returned for the said
  resource/action, a PERMIT is returned
• If deny is returned, DENY is returned
• If error occurs or no decision about request,
  INDETERMINATE is returned

5
GT-XACML Library

• Helper classes
• Construct query/decisions
• Attribute processing
• Missing pieces
• Signature
• Only SSL-authNed AuthZ-Authority supported
• Obligations
• Discussing best obligationId-handler interface
• Source code and details
• http//www-unix.mcs.anl.gov/ranantha/xacmlPDP/Ra
  chana Ananthakrishnan ltranantha_at_mcs.anl.govgt

6
XACML Obligations (1)

• Obligations are not part of the XACML policy
  language
• Can be returned by any implementation of the
  XACML-2 authZ query interface
• Obligation Semantics
• "XACML provides facilities to specify actions
  that MUST be performed in conjunction with policy
  evaluation in the ltObligationsgt element. There
  are no standard definitions for these actions in
  version 2.0 of XACML. Therefore, bilateral
  agreement between a PAP and the PEP that will
  enforce its policies is required for correct
  interpretation. PEPs that conform with v2.0 of
  XACML are required to deny access unless they
  understand and can discharge all of the
  ltObligationsgt elements associated with the
  applicable policy. ltObligationsgt elements are
  returned to the PEP for enforcement."

7
XACML Obligations (2)

• Obligation is identified by URI
• With additional arbitrary list of XSI-typed
  values
• Element ltObligationgt
• The ltObligationgt element SHALL contain an
  identifier for the obligation and a set of
  attributes that form arguments of the action
  defined by the obligation. The FulfillOn
  attribute SHALL indicate the effect for which
  this obligation must be fulfilled by the
  PEP.ltxselement name"Obligation"
  type"xacmlObligationType"/gtltxscomplexType
  name"ObligationType"gt ltxssequencegt
  ltxselement ref"xacmlAttributeAssignment"
  minOccurs0 maxOccurs"unbounded"/gt
  lt/xssequencegt ltxsattribute name"ObligationId"
  type"xsanyURI use"required"/gt
  ltxsattribute name"FulfillOn" type"xacmlEffectT
  ype" use"required"/gtlt/xscomplexTypegt

8
XACML Obligations (3)

• Implementation
• ObligationId has to be mapped to specific handler
  that is called by the PEP
• Obligation parameter values are passed to handler
• Handler returns True/False determines PEPs
  Permit/Deny
• Standardization
• ObligationId-Handler mapping and configuration
  should be standardized in Java (and C)
• With standardization of Handlers interface for
  obligation-parameter passing
• OGF should be the right place for this

9
XACML Obligations (4)

• Obligation Versioning Issue
• AuthZ Svc does not know what kind of
  Obligations the calling party supports
• Complicates versioning and upgrading of
  obligation-handlers
• Requires brittle out-of-band sync
• Standardize supported-obligations attribute
• Calling party communicates supported-obligations
  as a list of URIs in an environment-attribute
  through the request context
• OGF should be the right place to standardize this

10
XACML Assertion Validation

• Normally Assertion Validation is done before the
  AuthZ Query
• Like validation of X509 (proxy-)certs, attribute
  certs, saml assertions, etc.
• The validation produces new attributes that are
  added to the authZ request context
• Centralizing attribute validation is a common
  goal for many deployments
• We standardize interfaces for that purpose
• However, we see a requirement to limit the number
  of external services calls and to combine the
  validation and authZ processing behind a single
  service
• Need to pass the unvalidated certs/assertions as
  part of the authZ query
• Note that validation service can still be called
  from authZ service
• Note2 that authZ Svc can validate assertions,
  enhance the request context with new attributes,
  and call other real authZ Svc
• Requires standardization of subject/environment-at
  tributes to pass base64 encoded x509-blobs or
  saml-assertions
• OGF should be the right place to standardize this

11
Next Steps

• Need Standardization effort for
• ObligationId-Handler mapping in Java (and C)
• supported-obligations env-attribute
• Subject/Env-attributes to communicate unvalidated
  X509-blobs and SAML-assertions