Transcript Cardea - Grid Computing at NCSA
Cardea
Requirements, Authorization Model, Standards and Approach Globus World Security Workshop January 23, 2004 Rebekah Lepro Metz [email protected]
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 What
to communicate with the authority 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
Message Structure
WS-Security XML Digital Signature SAML XML Digital Signature or XACML Header Body SOAP
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
WS-Security
SAML Request
SAML Response
XACML Processing
1. AuthZ Request 7. AuthZ Response Policy Decision Point 4. Request Context Context Handler 6. Decision 5. Policy * Policy Administration Point 2. Attribute Query 3. Attribute Policy Information Point *may occur before request initiated
Authorization Processing in Cardea
Principal
Cardea -Principal Request
1.
Attribute Authority Attribute Authority 4.
3.
2.
10.
9.
XML Firewall 5.
XACML PIP 8.
PEP AuthZ Authority 6.
7.
2a.
SAML/SOAP AuthZ Decision Attribute XACML Unspecified XACML PDP XACML Context Handler Data Store
Principal PEP 1.
Cardea -PEP Request
2.
7.
Attribute Authority Attribute Authority XML Firewall 6.
3.
AuthZ Authority 5.
XACML PIP 4.
4a.
SAML/SOAP AuthZ Decision Attribute XACML Unspecified XACML PDP XACML Context Handler Data Store
Principal
Cardea -Enforcement Info
PEP Attribute Authority 1.
2.
3.
4.
2a.
SAML/SOAP AuthZ Decision Attribute XACML Unspecified Data Store
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/20 03/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