Authorization BOF Minutes


The original BOF agenda is archived here: BOF Agenda

Slides are available at:
http://zuni.cs.vt.edu/grid-authz/bof-slides-1.pdf
http://zuni.cs.vt.edu/grid-authz/bof-slides-2-authz-frameworks.pdf

Introduction and Agenda (Markus Lorch)


There is a lot of discussion in the security area on authorization. Some believe that we should get started with more formal authorization work. So, we're proposing this working group.

We'd like to develop an inventory of existing authorization mechanisms and frameworks. Also, the WG will summarize authorization scenarios from GGF scenarios already in the works or completed. An important aspect is to find if there is any overlap with other groups and clarify what will be done by this group.

BOF Goals:
  • WG charter
  • Overlap with other WGs
  • Deliverables / Timeline

Proposed WG scope:
Provide guidelines for grid developers. Aim for guidelines such that people following them will have an easier time and we will not be stuck with one technology now and will have to change later.

Grid authorization mechanisms:
  • GSI gridmap plus OS user accounts
  • CAS
  • VOMS (local center authz service)
  • Akenti (dist stakeholder)
  • Legion (flexible access decisions at object method layer plus legion users map)
  • Condor authz (configurable access control on protocol operations, peers can negotiate authn mechanism. ClassAd matchmaking uses the classad language to describe attributes on objects plus constraints, including security constraints)
  • Related mechanisms (WS-Authorization, PERMIS, PRIMA, Shibboleth, ...)

There are lots of approaches, but everyone does their own thing as nobody has guidelines to follow for interoperability.

Authorization Frameworks (Leon Gommans, Univ of Amsterdam)


RFC 2904:
  • A framework for authorization communication sequences, roles, and functions.
  • Originated from IRTF AAA architecture research group.

Generic AAA framework basic principles: pull sequence, agent sequence, and push sequence. Push is typical in the grid. AAA entity issues credentials. Also consider roaming scenarios and distributed services over multiple administrative domains.

Other frameworks:
  • ISO 10181-3 Access Control Framework
  • PERMIS: Similar to ISO model but implemented as agent model

RFC 2903 Generic AAA Architecture:
  • Based on IETF resource allocation protocol (rap) working group.
  • Has a policy decision point which renders a decision in response to a request, which is sent to a policy enforcement point.
  • Split pdp function: one is rule based engine, which is not aware of anything for conditions/actions of policies, one is application-specific.
  • By allowing rule based engines to talk to each other, we can bring together policies. So the policy decision is done by a number of policies behind the request.

Conclusion:
A concepts document can give a better overall picture.
It should describe existing and emerging (OGSA) mechanisms.

Existing AuthZ and Privilege Management Frameworks, APIs, and Standards (Markus)


Available documents in other groups:
  • Security implications of typical grid computing usage scenarios
  • EDG security requirements
  • Grid CP/Trust model
  • GSI multiple credredential scenarios

Work in progress:
  • Large site aaa doc
  • ACE security
  • OGSA security

Review of grid security implications document:
  • Simple ways for users to request rights plus allocations and for stakeholders to grant rights.
  • Issues with local user accounts
  • Superscheduler example.
  • Definitions (user, principal, stakeholder, etc..)

Review of ACE security requirements document:
  • access grid, teleimmersion, remote vis, dynamic plus asynch env
  • auth related:
    • traditional requirements
    • unique requirements
    • lack of persistent central authority
    • collaborators need to see who else is active

Review and Discussion of Proposed Charter and Milestones


In charter, be compatible "with current and future grid architectures".

In charter goal, change classification to taxonomy?

Will these documents be specific to Grid computing? They're summarizing technologies that are broader than Grid computing. The documents are a first step, before working on APIs.

Leon's presentation was just to get us started down the path on existing work. The group will stay focused and not survey everything that is out there.

Is the document a survey of all authorization technologies? Focus on Grid computing requirements and mechanisms.

DAIS WG plans to have authorization requirements document to feed into this group's documents.

Can you fit the authz mechanisms into a single framework? If not is there any hope for interoperable authz frameworks? (Examples: authz based on ability to pay vs. authz based on group membership) Framework is meant as a classification or taxonomy; not the solution, but rather the territory that we are considering. Consider this a conceptual framework rather than a solution.

Should also identify mechanisms that are missing. Second document should address requirements, both those that can be met today and those that can't currently be met.

Is this effort too abstract? Will the world be different in a year and a half? Can we compact the schedule?
General consensus: have drafts of both documents ready for next GGF.

Where is interoperability in the description of the documents?
The second document could have guidelines for achieving interoperability.
Add to end of second deliverable: regard to this framework "and interoperability." WG should consider interoperability from the start.

Proposed addition to statement of second deliverable:
This framework is to be used as a basis for future API design (descriptive vs. proscriptive).

Should the documents be combined? Possibly.

A working group or research group?
A working group, with an associated timeline, for quick results.

If take bottom up approach, may be of low value long term, but if take too long with architecture/framework then also may have low long term value. This is a mixed approach.

A glossary should be included as one of the deliverables.
Should the glossary be updated periodically?
WGs have finite lifetimes, so periodic updates should not be part of the WG.
If an update is needed, form a new WG to work on the update.

Suggestion on charter: be more specific than "provide guidance"
"Define a framework for grid developers..."

This WG is currently not in conflict with other WGs but this could change.

Proposed schedule: submit drafts to editor in June 2003
20+ for votes. No votes against.

Volunteer authors found for the documents:
  • glossary/terminology document (assume rfc 2903 or ISO document, discuss on mailing list)
    • editor: Dane Skow
    • contributors: everyone on the mailing list
  • requirements
    • editor?
    • contributors: Jay Alameda, Jim Basney, Leon Gommans
  • conceptual grid authorization framework
    • contributors: Mary Thompson, Andrew, Lavanya, Leon Gommans, Rick Baker
    • editor?

Proposed WG chairs: Markus Lorch and Andrew McNab
Proposed Secretary: Jim Basney

Minutes composed by Jim Basney and Jay Alameda.

/public/users/mlorch/Grid-AuthZ/BOF Minutes Login | Web Editor | Full Editor
Last modified 10/15/02 6:59 PM by mlorch (history)
Site contents