220 likes | 356 Views
Speaks-for Credentials in GENI Tools , Services and Aggregates. GEC17: Developer Working Session July 22, 2013 1600-1730. Introduction. The goal of this discussion is to review the role of and plans for “Speaks-For” in GENI What is Speaks-for? Why do we need it?
E N D
Speaks-for Credentials in GENI Tools, Services and Aggregates GEC17: Developer Working Session July 22, 2013 1600-1730
Introduction • The goal of this discussion is to review the role of and plans for “Speaks-For” in GENI • What is Speaks-for? Why do we need it? • What do we have to do to make it happen? • When can we and should we have the capability ready?
Outline • Credential Generation - Gary Wong, Utah/Flux • ABAC and Speaks-For Credentials – Steve Schwab and Ted Faber, ISI • Proof of Concept – Marshall Brinn, GPO • Discussion and Forward Plan - All
The need for Speaks-For • GENI experimenters use different API’s to speak to different services • The AM API to speak to aggregates to manage resources • The different CH/SA/MA API’s to talk to authorities to manage credentials • [Hopefully to be unified in coming months]
The need for Speaks-for [2] But, in fact, people don’t speak these API’s directly: tools speak them on their behalf • Since these API’s are based on secure SSL connections, the “speaker” (the one sending/receiving API traffic) needs a certificate and private key. • If a tool has access to the experimenter’s cert and key, they are effectively “speaking as” the experimenters • There is no way for the service on the other side to know the difference between the tool and the user
The need for Speaks-for [3] • This has two problems: • Accountability: We want to be able to log that a given transaction was done by/for a given experimenter by a given tool • Privacy: We don’t want to require that an experimenter provide his/her private key to a tool, in violation of security/privacy best practices. (*) The solution is to enable the tool to “speak as” itself with its own cert and key, and “speak for” the experimenter when invoking GENI API’s (*) We distinguish between local and hosted tools. A tool on your desktop (e.g. omni) does not require uploading a private key and should be acceptable to “speak as” the experimenter.
Speaks-as: Essential Flow Experimenter Tool Service (AM, SA) 2) Tool working with or on behalf of user speaks to service with experimenter’s cert and key 1) Experimenter uploads cert and private key to tool
Speaks-for: Essential Flow Experimenter Tool Service (AM, SA) 2) Tool working with or on behalf of user speaks to service with its own cert and key, but passes: The speaks-for credential The public cert of the experimenter being spoken for A “speaks-for=experimenterURN” option on API call 1) Experimenter creates and signs (with their private key) a “Speaks For” Credential indicating that a given tool is allowed to speak for the experimenter (in some context).
Yes, but… • How does an experimenter generate this “speaks-for” credential? • What does it look like? What scope does it have? • What changes do AM and CH/SA API calls need to make to support speaks-for?
Gary Wong, Utah/Flux Speaks-for Credential Generator
Steve Schwab/Ted Faber, ISI Speaks-for credential Details
Marshall Brinn, GPO Speaks-for Proof of Concept
Overview • I’ve been working to implement an end-to-end ABAC-based speaks-for solution • Based on the GCF baseline: • Tool = omni • SA = gcf-ch • AM = gcf-am • Using the ISI libabac • I’ve got things working but • Only for create_slice in GCF-CH • Only for create_sliver in AM V2 I’d like to go over what I’ve done to review what I think needs to be done, if it sounds reasonable, how it could be done better, how it could be applied more generally.
What do I mean by “working”? • If omni asks for a slice or sliver AS mbrinn • Works fine • If omni asks for a slice or sliver AS omni but passing speaks_for=<mbrinn_urn> and omni_speaks_for_mbrinncredential and mbrinn cert • Works fine • If omni asks for a slice or sliver AS omni • Exception “Only users or tools speaking for users allowed to invoke SA/AM calls” • If omni asks for a slice or sliver as OMNI but passes speaks_for=<alice_urn> and omni_speaks_for_mbrinncredential • Exception “Speaks-for credential doesn't match speaks-for user”
Steps • Install ABAC (and add to PYTHONPATH) • Edit gen-certs.py and cert-util.py to create tool certs/urns • Create OMNI Tool Cert/Keys • Generate speaks-for credential $ wgethttp://abac.deterlab.net/src/abac-0.1.4.tar.gz $ tar xvfz abac-0.1.4.tar.gz; cd abac-0.1.4 $ ./configure $ make $ sudo make install $ export PYTHONPATH=abac-0.1.4/swig/python:$PYTHONPATH ./gen-certs.py --notAll --tool --directory /tmp --username omni python ABACManager.py --configabac.conf --credential "ME.speaks_for(ME)<-T" --outfileomni_speaks_for_mbrinn.xml abac.conf: [Principals] ME=/home/mbrinn/.gcf/mbrinn-cert.pem T=/home/mbrinn/speaksfor/omni-cert.pem [Keys] ME = /home/mbrinn/.gcf/mbrinn-key.pem
Steps [2] # For speaks-for testing speaks_for=/home/mbrinn/speaksfor/omni_speaks_for_mbrinn.xml speaking_for=/home/mbrinn/.gcf/mbrinn-cert.pem #speaking_for=/home/mbrinn/.gcf/alice-cert.pem cert=/home/mbrinn/.gcf/omni-cert.pem key=/home/mbrinn/.gcf/omni-key.pem • Edit omni_config • Edit omni(client) side to • pass speaks-for credential and speaking-for option • src/omnilib/frameworks/framework_gcf.py [CH Client] • src/omnilib/am_handler.py [AM Client] • Edit gcf (server) side to • handle speaks-for credential and speaking-for option • authorize tool to speak for intended user • src/geni/ch.py [CH Server] • src/geni/am/am2.py [AM Server]
Mods to: am2.CreateSliver [GCF Aggregate] • Look at ‘options’ for a ‘speaks-for’ entry. If found: • Load ABAC Context with these principals: • T = the caller (grab cert from SSL connection) • S = the requester (grab cert from credentials argument with subject matching URN in speaks-for option) • If not found, raise Exception (“NO credential found for speaks-for user”) • ME = the AM’s own cert and key • Load ABAC Context with this statement • ME.speaks_for(S)<-S.speaks_for(S) • Load ABAC Context with any ABAC credentials in ‘credentials’ argument • Hopefully one is a statement that S.speaks_for(S)<-T • Ask ABAC to validate • ME.speaks_for(S)<-T • If not, raise Exception (“Tool cannot speak for Principal”) • Otherwise continue with existing authZ and CreateSlice logic. • Replacing cert of ‘speaker’ from SSL connection with ‘requester’ cert from credentials
Mods to: ch.CreateSlice[GCF CH/SA] • Need to add credentials/options arguments to match AM signature • Same logic as previous • Substituting ME = SA’s cert and key • In general, the preceding logic should be what is needed for any CH/AM call.
Mods to Omni • framework_gcf.get_slice_cred[GCF SA/CH client] • Add credentials, options to SA call • Add {‘speaks-for’ : user-urn} to options • Add user credential and speaks-for-credential to credentials • amhandler.create_sliver [GCF AM client] • Same
Helper modules in GCF src/abac • ABACManager.py: Provides wrapper class around libabac to: • Define principals by certs/keys and associate with names • Ingest assertions, credentials in ‘raw’ and ‘natural’ ABAC-style • Translating RT1_lite to RT0 hash labels • E.g. S.speaks_for(S)<-T => • 173e01944a6546b10353370d6e380c946a4ec9bd.speaks_for_173e01944a6546b10353370d6e380c946a4ec9bd<-eb56b6301bcd0aaf93c36b400b9fdff544ce5000 • Load fixed policies and instantiate policy templates • Handle queries, generate credentials • speaksfor_util.py: Helper methods to help server-side processing of speaks-for credentials/options • defget_speaking_for(config): • defget_speaks_for(config): • defdetermine_speaker_cert(options, creds, config, default_cert): • defauthorize_caller(caller_cert, config):