# Presentation: 160437

## Policy Federation“The Final Frontier”

**Policy-2005 Workshop**
- Keynote, June 8, 2005, Stockholm, Sweden
- Frank Siebenlist
- (Argonne National Laboratory / University of Chicago)
- franks@mcs.anl.gov     -      http://www.globus.org/

## Outline

- The Globus Toolkit (GT)
- (Grid) Use Cases
- Virtual Orgs (VOs), multiple admin realms, delegation
- Policy, Policy, Policy....
- Attributes
- Shibboleth, SAML, X509-ACs, VOMS, etc.
- Authorization
- Call-out, SAML Authz, XACML, PC, PERMIS, AAA-tk, Delegation...
- Authorization Processing Framework
- Attribute collection, generic PDP-abstraction, Master-PDP, Delegation/Rights-Admin
- Summary

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Globus Toolkit (GT-4.0)

- WS, WS-I & WSRF compliant toolkit
- WSS, WS-I, X509/(GGF-)SAML Identity/Attribute Certificates, X509 Proxy-Certificate, XACML, PERMIS, VOMS compliant toolkit
- Message Level Security  & TLS support
- Different platform support
- Java, C/C++, Python, .Net/C#
- (Security-)Integrated with higher-level Svcs
- GridFTP, GRAM, MDS, MyProxy, PURSE, OGSA-DAI...
- Many, many parties involved
- Customer-requirements driven
- ... with commercial “versions”...
- Open Source
- Apache-style license

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Leverage (Open Source) Security Service Implementations

- OpenSSL
- “native” Proxy Certificate support coming...(thanks to OpenSSL hacker Richard Levitte and KTH!)
- Internet2’s OpenSAML
- Part of GT - used by CAS/GridShib/AuthzCallout/...
- Internet2’s Shibboleth
- NSF funded GridShib project to “Grid-enable” Shibboleth
- Sun’s open source XACML effort
- Integrate sophisticated policy decision engine in the GT
- Futures: Permis, Handle System, XKMS, XrML, ...

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Security of Grid Brokering Services

- Brokers/Schedulers handle resource discovery, reservation, coordination, and usage on behalf of users
-  Each Organization enforces its own access policy
-  User needs to delegate rights to broker which may need to delegate to services
- QoS/QoP Negotiation and multi-level delegation

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Security Services Objectives

- It’s all about “Policy”
- (Virtual) Organization’s Security Policy
- Security Services facilitate the enforcement
- Security Policy to facilitate “Business Objectives”
- Related to higher level “agreement”
- Security Policy often delicate balance
- More security  Higher costs
- Less security  Higher exposure to loss
- Risk versus Rewards
- Legislation sometimes mandates minimum security

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Agreement  VO Security Policy

- Price
- Cost
- Obligations
- QoS
- T&Cs
- ...............
- Security
- ...............

- trust anchors
- (initial) members
- (initial) resources
- (initial) roles
- Access rules
- Privacy rules

**(Business) Agreement**

**Dynamic **
**VO Security Policy**

- members
- resources
- roles
- Attribute mgmt
- Authz mgmt

**Static Initial**
**VO Security Policy **

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Virtual Organization Concept

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Propagation of Requester’s Rights through Job Scheduling and Submission Process

- Dynamically limit the Delegated Rights more as Job specifics become clear

- Trust parties downstream to limit rights for you...or let them come back with job specifics such that you can limit them

- Virtualization complicates Least Privilege Delegation of Rights

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Security Services with VO

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## GT’s GGF’s Authorization Call-Out Support

- GGF’s OGSA-Authz WG: “Use of SAML for OGSA Authorization”
- Authorization service specification
- Extends SAML spec for use in WS-Grid
- Recently standardized by GGF
- Conformant call-out integrated in GT
- Transparently called through configuration
- Permis interoperability
- Ready for GT4!
- Futures...
- SAML2.0 compliance ... XACML2.0-SAML2.0 profile

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## GT-XACML Integration

- eXtensible Access Control Markup Language (XACML)
- OASIS standard
- Open source implementations
- XACML: sophisticated policy language
- Globus Toolkit ships with XACML runtime
- Integrated in every client and server build on GT
- Turned-on through configuration
- ...can be called transparently from runtime and/or explicitly from application...
- ...and we’re using the XACML-”model” for our Authz Processing Framework...

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## GT’s Assertion Processing “Problem”

- VOMS/Permis/X509/Shibboleth/SAML/Kerberos identity/attribute assertions
- XACML/SAML/CAS/XCAP/Permis/ProxyCert authorization assertions
- Assertions can be pushed by client, pulled from service, or locally available
- Policy decision engines can be local and/or remote
- Delegation of Rights is required “feature” implemented through many different means
**GT-runtime has to mix and match all policy information and decisions in a consistent manner...**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Basic Access Control Policy

- Can I have glass of lemonade?

- Ivan’s policy:
- Alice is my friend and I’ll share my lemonade with her
- Mallory is not my friend and he can go #$%^&

- Sure, here is a glass

- Can I have glass of lemonade?

- No way, I don’t like you

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Basic Access Control Policy (2)

- Can I have glass of lemonade?

- Ivan’s policy:
- Alice is my friend and I’ll share my lemonade with her
- Mallory is not my friend and he can go #$%^&

- Sure, here is a glass

- Can I have glass of lemonade?

- No way, I don’t like you

**Resource Owner decides!**
- (ultimate source of authority for access)

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Delegation of Rights (1)

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Delegation of Rights (2)

- Ivan’s policy:
- Carol is my friend and I’ll share my lemonade with her
- I’ll share my lemonade with any friend of Carol
- I don’t know any Bob...(?)

- Carol’s policy:
- Bob is my friend and I’ll share my lemonade with him

**Ivan likes Carol + Carol likes Bob**
**=> Ivan likes Bob**
- (non-normative delegation logic ;-) )

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Delegation of Rights (4)

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Delegation of Rights (5)

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Delegation of Rights (6)

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (1)

- Can I have glass of lemonade?

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (2)

- Can I have glass of lemonade?

**Master PDP**
**(Decision Orchestrator)**

**Subject**

**Invocation request for operation on resource**

**Policy/Decision Issuers**

**Resource Owner + Policy Issuer**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (3)

- Can I have glass of lemonade?

**Resource Owner + Policy Issuer**

**Subject**

**Invocation request for operation on resource**

**Master PDP**

**All AuthZ Decision Queries are asked **
**through Standardized Interface**
**All Decision Results are PERMIT/NotApplicable****(/DENY)**
**All differences in policy, policy language, kind/use of rules**
**are hidden behind the interface**

**Standardized AuthZ Query Interface**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (4)

- Can I have glass of lemonade?

**Policy/Decision Issuers**

**Resource Owner + Policy Issuer**

**Subject**

**Invocation request for operation on resource**

**Master PDP**

**Can subject invoke operation on resource?**

**Resource’s PEP asks ****Master-PDP**** for decision**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (5)

- Can I have glass of lemonade?

**Policy/Decision Issuers**

**Resource Owner + Policy Issuer**

**Subject**

**Invocation request for operation on resource**

**Master PDP**

**Can subject invoke operation on resource?**

**Master-PDP**** asks Resource Owner for decision**
**If resource owner permits, **
**then final decision is PERMIT, **
**because resource owner decides**
**else...**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (6)

- Can I have glass of lemonade?

**Policy/Decision Issuers**

**Resource Owner + Policy Issuer**

**Subject**

**Invocation request for operation on resource**

**Master PDP**

**Master-PDP asks all possible policy issuers one-by-one **
**if they allow the subject to invoke the operation on the resource**

**Can subject invoke operation on resource?**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (7)

- Can I have glass of lemonade?

**Policy/Decision Issuers**

**Resource Owner + Policy Issuer**

**Subject**

**Invocation request for operation on resource**

**Master PDP**

**Master-PDP asks all possible policy issuers one-by-one **
**if they allow the subject to invoke the operation on the resource**

**Can subject invoke operation on resource?**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (8)

- Can I have glass of lemonade?

**Policy/Decision Issuers**

**Resource Owner + Policy Issuer**

**Subject**

**Invocation request for operation on resource**

**Master PDP**

**For each policy issuer that permits the access,**
**The Master-PDP asks the resource owner **
**if that policy issuer is allowed **
**to administer the access to the resource**
**If so, final decision is PERMIT, else...**

**Can Carol administer access to resource?**

**PERMIT!**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (9)

- Can I have glass of lemonade?

**Policy/Decision Issuers**

**Resource Owner + Policy Issuer**

**Subject**

**Invocation request for operation on resource**

**Master PDP**

**For each policy issuer that permits the access,**
**The Master-PDP asks the other policy issuers **
**if that policy issuer is allowed **
**to administer the access to the resource**

**Carol permits**
**Bob access**

**Can Carol administer access to resource?**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## How to solve his AuthZ decision issue? (10)

- Can I have glass of lemonade?

**Policy/Decision Issuers**

**Resource Owner + Policy Issuer**

**Subject**

**Invocation request for operation on resource**

**Master PDP**

**Carol permits**
**Bob access**

**Laura permits**
**Carol to administer access**

**Can Laura administer access to resource?**

**PERMIT!**

**For each policy issuer that permits the administration,**
**The Master-PDP asks the resource owner**
**if that policy issuer is allowed **
**                      ****to administer the access to the resource**
**If so, final decision is PERMIT, else... **
**        ****try next level of delegation... until no more...**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## What are the Grid/peer-to-peer issues with “distributed authorization”? (1)

- Many different parties want to express their opinion about each other’s access rights
- Anybody can say anything about anyone else
- Expressed in many different languages
- Enforcement of single policy language impossible/not-desirable
- Some parties can be asked about their opinion
- Expose themselves as an AuthZ-oracle (PDP)
- Other parties send their opinion as statements
- Authenticated policy/decision statements/assertions expressed in their favorite language

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## What are the Grid/peer-to-peer issues with “distributed authorization”? (2)

- Some of that advise is from parties you’ve never met before
- So they must be empowered by those you do know...
- Some advise does not apply, is mal-formed, malicious, fake, erroneous, ....
- ...often you do not know that by looking at them...
- Different parties will use different names for the same subject
- Need identity federation for mapping
- Different parties will use different groups/roles in their policy expressions
- Only the group/role that is actually used in a relevant policy expression is of interest...

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Identity/Attribute Federation Requirements (1)

- Can I have glass of lemonade?

**Identity/Attribute Federation Requirements (1)**

**This is Bill**

**Aunt calls him William**

**His sister Rita calls him Will**

**His big brother David calls him Billie**

**Bill doesn’t want you to know what his girlfriend Olivia calls him...**

**Each of those policy issuers **
**express their policy-rules using “their”name for Bill**
**The  policy evaluator needs to map/federate those different names**
**in order to be able to apply the rules correctly**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Identity/Attribute Federation Requirements (2)

- Can I have glass of lemonade?

**Identity/Attribute Federation Requirements (2)**

**These are Emma’s “friends”**

**The attribute/group “friends” is local to the issuer**
**The  policy evaluator needs to maintain issuer info with local attributes**
**in order to be able to apply the rules correctly**
**At evaluation time we need to understand what are the “local names”, **
**“****global” names, or “guaranteed unique names within the context”**

**These are Lucy’s “friends”**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Negative Permissions are Evil!

- General advise: don’t use “Deny”
- “clarity” issues with understanding consequences of individual “deny” policy rules
- Policy becomes too complex too soon
- Pushing of Deny-assertions + DoS         => Security Exposure
- ...but, but, but, .... we need/want “deny”!
- No you don’t ;-)
- You want black-lists!

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Black List Services

- BL-PDPs return Deny or Not-Applicable
- Master-DPD treats “Permit” as Not-Applicable
- Only interested whether the black-list services _**deny**_ access to the subject
- They are not to be used for rendering of general purpose policy decisions
- Query the configured black-list services before the general purpose PDPs
- Pushing of black-list assertions or EPRs not allowed
- “Deny-Override” rules for the black-list services
- ...pragmatic way to address deny-requirements...
- note that you are still allowed to shoot yourself in the foot with deny-policies “behind” the PDP interface...

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Black-List PDPs/Services

- Can I have glass of lemonade?

**Black-List PDPs/Services**

**Resource Owner + Policy Issuer**

**Subject**

**Master PDP**

**For each decision query,**
**Master-PDP consults Black-List PDPs **
_**before**_** querying General PDPs **

**Black-List **
**PDPs**

**General**
**PDPs**

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Different Policy Languages Issue

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Requirement for an Policy Evaluation Service (“PES”)

- Like a PDP, but in addition, you also supply the policy rules/statements to evaluate
- PES is an (external) service that the relying party “trusts” to evaluate an AuthZ decision
- Solves the issue that not all runtimes have the evaluation engines available to determine whether received policy decisions/statements/assertions apply
- One PES implementation for each policy language flavor
- ...the PDP interface could be extended to accommodate policy statements as an input parameter

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Attribute/Authorization Processing

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Authz Processing Assumptions (1)

- All Policy Statements, PDPs and Authz-Decisions have Issuer associated with them
- “someone” has to take responsibility for statements and associated decisions
- Resource Owner is the Ultimate Authority
- Any statement/decision that can not be directly traced back to the owner is NotApplicable
- “traced back”: delegation chain that starts with owner
- Two different Policy Statements and Queries
- Admin Policy Statements
- Issuer states that certain admin-subject are allowed to administer the rights of certain access-subjects to invoke certain operations on certain resources.
- Access Policy Statements
- Issuer states that certain access-subject are allowed to invoke certain operations on certain resources.

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Authz Processing Assumptions (2)

- “Push-Pull” Equivalence
- Pushing authz-assertion and evaluating it locally renders same decision as evaluating the same policy statements remotely behind an external PDP
- Authz-Decisions are Policy Statements
- Folded over the request context
- Could optimize by only considering the attributes used to render a decision...
- If attributes don’t specify a “invocation context”, then only the invoker’s identity would suffice...
- Conservative: mandate that all request context’s attributes values are equal to the ones that rendered the decision.

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Attribute Collection Framework

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## GT’s Authorization Processing Model (1)

- Use of a Policy Decision Point (PDP) abstraction that conceptually resembles the one defined for XACML.
- Normalized request context and decision format
- Modeled PDP as black box authorization decision oracle
- After validation, map all attribute assertions to XACML Request Context Attribute format
- Create mechanism-specific PDP instances for each authorization assertion and call-out service
- The end result is a set of PDP instances where the different mechanisms are abstracted behind the common PDP interface.

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## GT’s Authorization Processing Model (2)

- The Master-PDP orchestrates the querying of each applicable PDP instance for authorization decisions.
- Pre-defined combination rules determine how the different results from the PDP instances are to be combined to yield a single decision.
- The Master-PDP is to find delegation decision chains by asking the individual PDP instances whether the issuer has delegated administrative rights to other subjects.
- the Master-PDP can determine authorization decisions based on delegated rights without explicit support from the native policy language evaluators.

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## GT Authorization Framework (1)

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## GT Authorization Framework (2)

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## GT Authorization Framework (3)

- Master-PDP accessed all mechanism-specific PDPs through same Authz Query Interface
- SAML-XACML-2 profile
- Master PDP acts like XACML “Combinator”
- “Permit-Overrides” rules
- Negative permissions are evil...
- Delegation-chains found through exhaustive search
- ...with optimization to evaluate cheap decisions first...
- “Blacklist-PDPs” are consulted separately
- Statically configured, call-out only PDPs
- Deny-Overrides only for the blacklist-PDPs...
- Pragmatic compromise to keep admin simple

- Policy2005 Workshop: Policy Federation

- June 8, 2005

## Summary

- Policy Federation through Interface Abstraction
- Addresses Grid/peer-to-peer multi-AuthZ requirements
- Generic Authz Processing Framework
- Mix, match and combine different authz mechanism
- Supports delegation as “side-effect”
- Proto-type => GT-4.2 integration
- Both Attribute Collection & Authz Processing
- Java, Python, C/C++ (,.Net) ... WS & GridFTP & httpd
- XACML-3 (?)
- May be able to incorporate “all” our processing requirements
- Could function as an AuthZ Policy Federator
- The Final Frontier?
- ...for me it is ;-)

- Policy2005 Workshop: Policy Federation

- June 8, 2005