1 / 34

Cardea

Cardea. Requirements, Authorization Model, Standards and Approach Globus 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”

jola
Download Presentation

Cardea

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cardea Requirements, Authorization Model, Standards and Approach Globus World Security Workshop January 23, 2004 Rebekah Lepro Metz rlepro@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 whichauthority 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. 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 Conceptual Overview

  16. Header XML Digital Signature SOAP XML Digital Signature Body 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. <Signature> <SignedInfo> <Reference/> </Reference> </SignedInfo> </Signature> XML Digital Signature <CanonicalizationMethod/> <SignatureMethod/> <Transforms/> <DigestMethod/> <DigestValue/> <SignatureValue/> <KeyInfo/>

  21. <SOAP:Header> <Security> <Signature> </Signature> <BinarySecurityToken> <Reference URI=“#msgBody”/> <KeyInfo/> <SecurityTokenReference/> <KeyInfo/> </ BinarySecurityToken > </Security> <SOAP:Body ID=“#msgBody> </SOAP:Header> </SOAP:Body> WS-Security

  22. *SAML relies on XML Digital Signature to guarantee request natively to SAML <Request RequestID=“1234”> <AttributeQuery Resource=“uri”/> <AuthZDecisionQuery Resource=“uri”/> <Signature/>* </AttributeQuery> </ AuthZDecisionQuery > </Request> SAML Request <RespondWith/> <Subject/> <AttributeDesignator/> OR <Subject/> <Action/> <Evidence/>

  23. <Response InResponseTo=“1234”> <Assertion> <AttributeStatement> <AttributeStatement> <AuthZDecisionStatement Decision=“Permit”> </Assertion > </AuthZDecisionStatement> </Response> SAML Response <Signature/> <Status/> <Signature/> <Subject/> <Attribute/> or/and <Subject/> <Action/> <Evidence/>

  24. 1. AuthZ Request 7. AuthZ Response 4. Request Context 6. Decision 5. Policy* 2. Attribute Query 3. Attribute *may occur before request initiated XACML Processing Policy Decision Point Context Handler Policy Administration Point Policy Information Point

  25. Authorization Processing in Cardea

  26. Attribute Authority 1. Attribute Authority Attribute Authority 2. 10. 5. 2a. 7. 6. XACML Context Handler XACML PDP SAML/SOAP Data Store AuthZ Decision Attribute XACML Unspecified Cardea -Principal Request Principal 3. XML Firewall 4. 9. XACML PIP 8. AuthZ Authority PEP

  27. Principal Attribute Authority Attribute Authority Attribute Authority 1. 2. 3. 4a. 4. 5. XACML Context Handler XACML PDP SAML/SOAP Data Store AuthZ Decision Attribute XACML Unspecified Cardea -PEP Request XML Firewall XACML PIP 7. 6. AuthZ Authority PEP

  28. Principal 1. 2. 2a. SAML/SOAP AuthZ Decision Attribute Data Store XACML Unspecified 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_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

More Related