Cardea

1
Cardea

• Requirements, Authorization Model, Standards and
  Approach
• Globus World Security Workshop January 23, 2004

Rebekah Lepro Metz rlepro_at_arc.nasa.gov
2
Cardea

• What does Cardea mean?
• Cardea was a goddess of thresholds who held the
  ability to open what was shut and close what was
  open
• What does Cardea do?
• Provides dynamic access control in a distributed
  computing environment

3
Requirements
4
Requirements

• Decouple authentication and authorization
• Establish a process to securely authenticate grid
  users and authorize them to local resources
  without requiring a pre-existing account on each
  resource
• Permit the IPG to recognize/handle credentials
  issued by trusted domains even if it does not use
  the same credentialing mechanism as the IPG
• Permit users to transparently access any resource
  available (even across administrative boundaries)
  on the IPG according to their authorizations
• Minimize administrative access required to
  provide dynamic access to resources

5
Requirements

• Preserve domain autonomy
• Support data or data-consumers in arbitrary
  locations
• Separate user administration from resource
  administration
• Accommodate unique internal configurations
• Minimize restrictions on participation due to
  configuration differences.
• Increase the interoperability in the face of
  configuration differences
• Transparently handle site differences in policy
• Integrate new or modified policies as they are
  developed

6
Requirements

• Interoperate with existing security
  infrastructures
• Support multiple credential and enforcement
  mechanisms
• Provide functionality regardless of the existence
  or lack of specific features of an underlying
  system or subsystem
• Allow each participating site to enforce their
  unique local access control
• Provide sufficient information to local
  enforcement mechanisms to execute their duties
  within the local domain

7
Problems to Address

• Participating sites are within separate
  management domains but within the same grid
  virtual organization (GVO) and/or in different
  GVOs
• Neither the mechanisms to identify the
  appropriate local policies to enforce nor execute
  the actual enforcement of these policies
  typically exist
• Most transactions occur across administrative
  boundaries in an asynchronous manner
• Continually changing user and resource base

8
Modeling Authorization
9
Communication Paradigm(s)

• The selected communication paradigm must
  consider
• A framework to pass messages and meta-data
  layered on various transport protocols
• Standards compliance
• Support for the concepts of requester and
  authority identity
• Integration with web service/XML processing
• Availability of development tools and libraries

10
Information Representation

• The model must represent information to
• Distinguish between identity and information
  bound to identity
• Base authorization decisions on classes of
  information
• anonymous
• identity-specific
• characteristic-based (standard or custom
  definitions)
• Transform during the authorization process if
  necessary
• Standardize representation

11
Authority Discovery and Interaction

• The model must establish
• How to identify which authority to contact
• How to communicate with the authority
• What to communicate to the authority
• Support for authorization requests for local and
  remote resources and local and remote requesters

12
Authorization Decision Algorithm

• The model must establish
• What information is required and how it is
  collected
• Flexibility to support a variety of site-specific
  decisions
• Support for multiple stakeholders
• Well-defined decision processes
• Separation from enforcement mechanism

13
Technical Approach
14
Conceptual Overview
SAML
XACML
XML DSig/ WS-Security
15
Conceptual Overview

• Identifies four phases of authorization
• Initial Request
• Evaluation
• Decision
• Enforcement

• Components communicate within each phase to share
  necessary information
• SOAP message based
• Message contents standardized and vary by phase

16
Message Structure
WS-Security
SAML
or
XACML
17
SAML - Why?

• Native XML standard
• Protocol and assertion format to exchange
  information on authentication and authorization
  acts and entity/principal characteristics
• Mechanisms to include evidence and meta-data
  related to asserted statements

18
XACML - Why?

• Native XML standard
• Represent access control policy
• Standard framework for representing variety of
  access control policies in common format
• Consideration for the authorization requirements
  of multiple stakeholders represented distributed
  policies
• Evaluate access control decisions
• Locate and apply appropriate security policies
• Evaluate requests according to well-defined
  functions and issue well-defined decisions

19
Introduction to the Standards
20
XML Digital Signature
ltCanonicalizationMethod/gt
ltSignatureMethod/gt
ltTransforms/gt
ltDigestMethod/gt
ltDigestValue/gt
ltSignatureValue/gt
ltKeyInfo/gt
21
WS-Security
22
SAML Request
ltRespondWith/gt
ltSubject/gt
ltAttributeDesignator/gt
OR
ltSubject/gt
ltAction/gt
ltEvidence/gt
23
SAML Response
ltSignature/gt
ltStatus/gt
ltSignature/gt
ltSubject/gt
ltAttribute/gt
or/and
ltSubject/gt
ltAction/gt
ltEvidence/gt
24
XACML Processing
Context Handler
Policy Decision Point
Policy Administration Point
Policy Information Point
25
Authorization Processing in Cardea
26
Cardea -Principal Request
Principal
3.
XML Firewall
4.
9.
XACML PIP
8.
AuthZ Authority
PEP
27
Cardea -PEP Request
XML Firewall
XACML PIP
7.
6.
AuthZ Authority
PEP
28
Cardea -Enforcement Info
PEP
Attribute Authority
3.
4.
29
Design Issues
30
Key Design Points

• Policy is defined directly in terms of attributes
  (subject, resource, action)
• Principal/PEP knows how to represent identity
  credential within SAML ADQ
• Attribute identity and semantics are established
  by the user community
• Principal/PEP/Authority know how to contact
  appropriate Authorities for info

31
XML Firewall

• Provides the ability to filter requests according
  to the identity of the sender which may be either
  the principal, a proxy for the principal or the
  PEP itself.
• SAML requests contain only information about the
  SUBJECT of the request which may differ from the
  requester
• Separates verification of the WSS information
  embedded in SOAP messages from payload processing

32
XACML PDP within SAML Authorization Authority

• SAML AuthorizationDecisionQuery and Statements
  only provide framework for asserting decisions
  made by an authority
• XACML processing provides the mechanism to reach
  the decision to be asserted within that framework
• Maintain state during decision process
• Provide additional information to PEP if needed
  to execute enforcement of decision

33
Attribute Authority within PEP

• Provides a mechanism for the PEP to report
  information about how an Authorization was
  enforced
• Provides mechanism to separate enforcement
  information by request rather than by principal
• Does not provide a mechanism to manipulate the
  enforcement.
• This would require appropriate authorization
  which can be handled by initiating a separate
  request within the authorization process to
  modify the enforcement

34
For More Information

• Cardea - http//www.nas.nasa.gov/Research/Reports/
  Techreports/2003/nas-03-020-abstract.html
• SAML - http//www.oasis-open.org/committees/tc_hom
  e.php?wg_abbrevsecurity
• XACML - http//www.oasis-open.org/committees/tc_h
  ome.php?wg_abbrevxacml
• XML DSig - http//www.w3.org/TR/xmldsig-core/
• WSS - http//www.oasis-open.org/committees/tc_home
  .php?wg_abbrevWS-Security