| | 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 |
