CardeaRequirements, Authorization Model,

Standards and ApproachGlobus World Security Workshop January 23, 2004

Rebekah Lepro Metz

rlepro@arc.nasa.gov

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

Requirements

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

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

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

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

Modeling Authorization

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

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

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

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

Technical Approach

Conceptual Overview

SAML

XACML

XML DSig/WS-Security

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

SOAP

Message Structure

HeaderWS-Security

Body

SAML

XACML

XML Digital Signature

XML Digital Signature

or

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

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

Introduction to the Standards

XML Digital Signature

</Signature>

<Signature><SignedInfo>

</SignedInfo>

<KeyInfo/>

<SignatureValue/>

<CanonicalizationMethod/>

</Reference>

<Reference/><SignatureMethod/>

<Transforms/>

<DigestValue/>

<DigestMethod/>

WS-Security

</SOAP:Header>

<SOAP:Header><Security>

</Security>

</ BinarySecurityToken >

<BinarySecurityToken>

<Signature>

</Signature>

</SOAP:Body><SOAP:Body ID=“#msgBody>

<KeyInfo/>

<KeyInfo/>

<Reference URI=“#msgBody”/>

<SecurityTokenReference/>

SAML Request

</Request>

<Request RequestID=“1234”><RespondWith/>

<Subject/><AttributeDesignator/>

<Subject/>

<Evidence/><Action/>

OR

<AttributeQuery Resource=“uri”/>

</AttributeQuery>

<AuthZDecisionQuery Resource=“uri”/>

</ AuthZDecisionQuery >

<Signature/>*

*SAML relies on XML Digital Signatureto guarantee requestnatively to SAML

SAML Response

</Response>

<Response InResponseTo=“1234”>

<Assertion>

</Assertion >

<Signature/>

<Signature/>

<Status/>

<Attribute/>

<Subject/>

<Subject/>

<Evidence/><Action/>

<AttributeStatement>

<AttributeStatement><AuthZDecisionStatement Decision=“Permit”>

</AuthZDecisionStatement>

or/and

XACML Processing

ContextHandler

PolicyDecision

Point

Policy InformationPoint

Policy Administration

Point

1. AuthZ Request 7. AuthZ Response

3. Attribute

6. Decision

2. Attribute Query

4. Request Context

5. Policy*

*may occur before request initiated

Authorization Processing in Cardea

Cardea -Principal Request

AuthZ Authority

XACMLContextHandler

XACMLPDP

Attribute AuthorityAttribute AuthorityAttribute Authority

XACMLPIP

PEP

Principal

XMLFirewall

SAML/SOAP

AuthZ Decision

Attribute

XACML

Unspecified

1.

2.

2a.

Data Store

3.

5.

6. 7.

10.

8.

9.

4.

Cardea -PEP Request

AuthZ Authority

XACMLContextHandler

XACMLPDP

PEP

Attribute AuthorityAttribute AuthorityAttribute Authority

XACMLPIP

Principal

XMLFirewall

SAML/SOAP

AuthZ Decision

Attribute

XACML

Unspecified

7.4a.

Data Store

3.

5. 4.

1.

6.

2.

Cardea -Enforcement Info

Attribute Authority

PEP

Principal

SAML/SOAP

AuthZ Decision

Attribute

XACML

Unspecified

1.

Data Store

2a.

2.

3.4.

Design Issues

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

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

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

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

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_home.php?wg_abbrev=security

• XACML - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

• XML DSig - http://www.w3.org/TR/xmldsig-core/• WSS -

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=WS-Security