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. 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. SOAP Message Structure Header WS-Security Body SAML XACML XML Digital Signature or

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

21. WS-Security

22. SAML Request OR * *SAML relies on XML Digital Signature to guarantee request natively to SAML

23. SAML Response or/and

24. XACML Processing Context Handler Policy Decision Point Policy Information Point 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

25. Authorization Processing in Cardea

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

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

28. Cardea -Enforcement Info Attribute Authority PEP Principal SAML/SOAP AuthZ Decision Attribute XACML Unspecified 1. Data Store 2a. 2. 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/20 03/nas-03-020-abstract.html 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=securityhttp://www.oasis- open.org/committees/tc_home.php?wg_abbrev=security XACML - http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=xacmlhttp://www.oasis- open.org/committees/tc_home.php?wg_abbrev=xacml XML DSig - http://www.w3.org/TR/xmldsig-core/http://www.w3.org/TR/xmldsig-core/ WSS - http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=WS- Securityhttp://www.oasis- open.org/committees/tc_home.php?wg_abbrev=WS- Security