Changes between Version 8 and Version 9 of GEC10Auth


Ignore:
Timestamp:
04/11/11 15:09:19 (8 years ago)
Author:
tmitchel@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC10Auth

    v8 v9  
    4747 Session wrap-up - Tom Mitchell (10 mins)[[BR]]
    4848
     49==== Community Agreement from the Meeting ====
     50 * ABAC should be added to the GENI AM API as an alternative means of authorization
     51  * Does not replace existing credentials
     52  * Allow gaining experience with ABAC
     53 * An existing aggregate should be ABAC-enabled
     54  * Aggregates are not required to add ABAC support
     55  * Allow gaining experience with ABAC
     56  * ProtoGENI AM is the likely first target
     57  * Experience and proposed next steps to be reported at GEC11
     58 * Limit the ABAC 'experiment' to 1 year
     59  * Either select it or reject it within that time frame
     60
     61==== Next Steps ====
     62  * ISI: Integrate ABAC assertion handling into ProtoGENI AM (w/GPO support)
     63  * ISI: Implement existing access rules as ABAC assertions
     64  * ISI: Issue ABAC assertions for existing users
     65  * ISI: Explore richer assertions and policy rules within ProtoGENI code base
     66  * ISI: Report results by GEC11
     67
     68==== Selected Discussion Points ====
     69===== Steve Schwab =====
     70 * Current authorization
     71  * Current authorization mechanism uses SFA credentials: signed XML documents
     72  * Currently: Roles map to privileges map to operations. Messy
     73  * In practice, only the slice authorities make authorization decisions: Aggregates simply accept slice credentials issued by trusted slice authorities.
     74 * Authorization goals
     75  * Support many policies: different aggregates, resources, groups
     76  * Support many users and groups of users
     77  * Uniform language for authorization policy
     78  * Support auditing
     79 * ABAC is flexible, with a well founded logic and formulism
     80 * ABAC supports logging with proofs of why access was granted or denied
     81 * ABAC attributes could map 1:1 to existing credentials. Ted has illustrated this.
     82 * Could instead have ABAC attributes map 1:1 to operations.
     83 * No need for global agreement on attributes: only need to agree at both the spot they are generated and the spot they are consumed
     84 * ISI / TIED project have described encoding existing AM API rules as ABAC assertions, and how to integrate ABAC into the GENI AM API (see the meeting background reading).
     85 * Plan
     86  * Try within ProtoGENI and discuss at GEC11
     87  * Build reference policies for AMs
     88  * Adapt current rules to start, then simplify
     89  * Support both credentials for now
     90  * Will invite others to try it prior to GEC11
     91 * Tools for manipulated assertions & policies are needed; ISI demonstrated some at demo night
     92
     93===== Jeff Chase =====
     94 * ABAC is consistent with basic GENI security agreements
     95 * Beauty of ABAC is that anyone can be a trust anchor: AMs just need to trust them
     96 * External identity providers can be sources of attributes
     97 * Note that resource allocation decisions may involve limits on quantities, etc
     98  * ABAC may not be sufficient
     99 * ABAC supports delegating privileges, which is important
     100 * May need parametrized attributes - like a limited RT1
     101  * the creator of an object may have special rights
     102 * There's a difference between delegating to someone (I'm no longer responsible) and allowing someone to speak for me (eg a proxy service)
     103  * May need a !SpeaksFor attribute
     104
     105===== Rob Ricci =====
     106 * Existing mechanism in use for about a year successfully
     107 * Existing mechanism is based on capabilities NOT role like ABAC.
     108  * Be clear
     109 * Policies should be explicit, not in text as currently
     110 * Avoid complex logic that people won't understand
     111 * Avoid negotiation of what attributes to pass
     112 * Provide useful feedback on failed access, maybe indicating next step
     113 * Trust boundaries: Can we bound what slices authorities can act on? Is RT1 needed for this?
     114 * Maximize tool support
     115  * Existing ISI ABAC library uses poorly supported certificate format, which isn't good
     116  * Simple clients should be able to parse attributes without full inference engine
     117 * Limit parallel authorization schemes to 1 year
     118
     119===== Group =====
     120 * Existing implementation doesn't handle dates well. RT1 does more
     121 * Improving returns from AM API would help with explaining failures
     122 * Existing library exists to read and manipulate assertions from multiple languages
     123 * Avoid complex issues like negotiation
     124 * Standard error codes would be nice
     125 * Want to be able to say things like "members of group X can allocate up to Y amount of resource Z"
     126  * RT1 would support that
     127 * Ted says: RT1 expected this summer
     128 * GENI is not a research program. Build simple infrastructure.
     129 * SAML vs X509 assertions?
     130  * SAML would appear to offer better tool support, but...
     131  * Need to find an existing SAML implementation
     132 * How should we support numeric computations?
     133 * Will need common language of basic assertions so we can be consistent
     134 * Be nice to users and admins: not too complex, provide good tools
    49135
    50136==== Background reading ====