AuthZ Telecon 2003-06-03, 16:00 UTC

Attendees
Andrew McNab
Markus Lorch
Leon Gommans
Rich Baker
Mary Thompson
Dane Skow
Bob Cowles
Lavanya Ramakrishnan
Jim Basney (secretary)

Call Summary
The call was focused on a section-by-section review of the framework
document. The submission deadline for GGF8 is Friday (but does that
really mean Monday morning? Markus will check.). There's a need for
more editing of the document, for consistency of terms and to avoid
overlapping sections. Privilege delegation was a major topic of
discussion, to be addressed in section 2.1. The notion of a
credential collector, proposed on the list by Krishna, was suggested
as a discussion topic for a GGF8 session.

Volunteers:
Markus and Leon will work on sections 1-3.
Mary will work on section 4, with a new diagram provided by Markus.
Lavanya will work on section 5.
Bob will continue to serve as editor (coordinating with Markus).

Topics for discussion on the mailing list:
Subject Authority vs. Attribute Authority (w.r.t. delegation).
Does OGSI/OGSA figure/example fit in section 3? What does figure 3-2 mean?
Continuation of the "Section 4.6 Enforcement Mechanisms" thread.

Call Minutes
Review of framework document. Assign people to complete sections.
Goal: Complete framework document by Friday.
Start of discussion of Section 2: Concepts.
Leon's comments weren't incorporated.
Figures do contain the names, so that's OK.
Some inconsistent terms with section 3, pointed out by Leon.
What about service owner? Markus wants to leave owner out of
discussion, as the owner doesn't matter for authz. Only Authority.
Owner gives the authorization. Doesn't matter if you're the owner,
we just care about the authority.
Example: resources owned by university but PIs have authority.
Also, system administrator implements policy.
Legal entity that owns the resource will come up in practice
statements.
May be multiple authorities for a single resource.
Notion of ownership can be problematic. Use stakeholder instead?
Make it clear in section 2 that owner is not meant in a legal sense.
How is owner different from authority then?
There are many types of authorities that define rules.
There are subjects, resources, and authorization servers that enforce
rules.
Section 3 introduces different types of authorities.
But the different authorities are also listed in section 2.
Too much for section 2?
Consensus to keep it more general in section 2. Introduce multiple
authorities in section 3.
Using XACML terms in section 2. Should include a reference.
Types of Authority discussed at PKI workshop: Resource, Policy, Environmental.
Do we issue attributes to subjects or to roles?
A role is an attribute of a subject.
The role definition is not an attribute. It's in the policy or role
definition document, outside of attribute.
Can subjects delegate identity or authority?
Must be defined in the policy of the resource accepting the delegation.
Roles help with privilege management. Manage rights for a group and
can have hierarchical roles.
Refer to PERMIS paper (discretionary access control models and
role-based access control).
If I delegate rights, I'm a subject authority but not an attribute
authority?
XACML and SAML don't address the delegation scenario much but it's
important for Grids.
There's no term for a delegated attribute. Markus calls them
privileges. A policy statement combined with the action.
The policy says who can give other people rights, who can act as an
authority and for what.
Is subject authority more/less general than attribute authority?
Iron out subject vs. attribute authority on mailing list, in
particular w.r.t. delegation.
Similar to difference between CA and user delegating identity cert
(proxy cert).
Limit scope of attribute certificate delegated to a proxy?
A limited proxy?
Discussion of delegating additive vs. subtractive privileges.
Subtractive privileges fails open, if you forget to subtract a right.
The document needs to address delegation in section 2.1.
Conclusions for section 2:
  • Need to make sure terminology is consistent throughout document.
  • Remove notion of authority from Service Provider. Have subject,
resources, and authorities.
Provider is active vs. resource is passive.
Same for subject: can have a subject agent.
So resource is similar to subject and authority. They each have
agents/servers.
  • Some details in section 2 need to move to section 3. Example: ADF/AEF
Discussion of section 3.
Krishna proposed credential collector on the mailing list.
Is it a functional entity of the model or an implementation detail?
Federated identity.
A topic for discussion at GGF8?
In section 2.5, hybrid model, you could pass a handle to a credential
collector.
Objection to OGSI/OGSA example and figure in section 3.
Figure 3-2 doesn't make sense to the group and is OGSI-specific?
We want a discussion of APIs vs. protocols. Where is it?
OGSA security roadmap reference is an example?
Need to discuss more on mailing list.
Discussion of section 4.
Overlapping privilege management and authority?
Attributes, delegation, and authorization.
We need an editor.
It started to become clear that most people hadn't read the document
before the call?
Privilege management section is too broad?
Split between privilege management and access control.
Privileges is rights to do something and attributes is the way rights
are expressed.
Privileges are assigned to entities.
Policies are assigned to resources.
AuthZ servers (enforcement points) combine privileges w/ policies to
make decisions.
Define the terms in a picture?
Privileges are associated with roles (and people?).
Roles assigned to identities.
Markus will look at OASIS XACML view and work on a picture.
Trust management is overall thing?
Privilege management on one side and access control on the other side?
Access control is more limited term than authorization?
Mary will take Markus's picture and modify the text of section 4, to
take care of overlap between privilege management and authz service.
Markus will go through the whole document and incorporate Leon's
comments, working with Leon.
Section 5: Move details to appendix. Lavanya will work on it and
submit by tomorrow.
Bob will combine sections.
GGF8 document submission deadline is June 6 (Friday). Probably means
Monday in practice, since they won't process submissions until Monday?
Markus will check.
Bob needs sections by Sunday afternoon (US time).
Cees says terminology should be defined along the lines of RFC 2026.
The framework is an informational document.
Section 4.6 Enforcement Mechanisms: discussion between Markus and
David on mailing list.
Enforcement means user has access to a service vs.
user creates a service and what resources does it have access to.
User authz to stationary services (access decision on web services
layer) vs. (for example) access control for legacy parallel codes.
Akenti enforces access control at web server. If you're running
scripts, the script itself must make call-outs to Akenti.
You have to trust the script. It polices itself.
You have/need layers of access control.
Sandboxing the application.
Application-dependent enforcement vs. application-independent
enforcement (sandbox).
Sandboxing is hard.
Please read what Markus has written on the mailing list regarding
section 4.6 and comment.

/public/users/mlorch/Grid-AuthZ/Telecon Minutes 2003-06-03 Login | Web Editor | Full Editor
Last modified 6/24/03 12:43 PM by mlorch (history)
Site contents