GEMINI: 101112 gemini_aa.txt

File 101112 gemini_aa.txt, 10.8 KB (added by, 10 years ago)
1== GEMINI AA Planning ==
4This document provides details on the AA workflow diagram created by Guilherme.
5Refer to AA-workflow.png. The proposed model remains relatively unchanged from
6the diagram.
8The following discussion assumes a UNIS implementation using ABAC 0.2.2, the
9current stable release from ISI.
14In the context of GENI, the basis for authentication and authorization to an I&M
15service (e.g., UNIS) is the user certificate and private key.  These
16certificates (cert) are obtained from a trust authority, e.g., Utah or the GPO.
18 - user.pem
19 - user.key
21For each service that interacts within the I&M system, we want to generate a
22identity (key pair) to provide access control via proxy certs.  Our original
23approach in LAMP generated a dedicated lampcert for this purpose, which allowed
24for unrestricted access between services.  A proxy cert per service will
25eventually allow the user (i.e., slice owner) to delegate access to I&M services
26at different granularities.
28The proxy certs are signed by the user cert, meaning a proxy cert is validated
29against the service as if the request was made by the user.  However, attributes
30that are assigned to the service identity can restrict authorized use for each
31proxy cert.
33Example of how to create service identity and proxy certificates:
35$ openssl req -new -config csr.conf -out blipp_service.csr -keyout blipp_service.key
36$ openssl x509 -req -CAcreateserial -in blipp_service.csr -days 365 \
37  -out blipp_service_ID.pem -CA user.pem -CAkey user.key \
38  -extfile csr.conf -extensions v3_proxy
40We now have a service proxy cert:
42 - blipp_service_ID.pem
44The proxy cert is concatenated with the user cert to maintain the chain of trust
45and is pushed to the service nodes.  The service now uses this proxy cert to ask
46for resources on a service like UNIS.
48Now that we have proxy certs per service, we need to create ABAC credentials.
49We use the slice credential to effectively associate the user with the
50experiment slice when defining ABAC roles and to determine the lifetime (up to
51slice expiration time) of said roles.  While there are a number of ways to
52create and maintain attributes and policies, the following section outlines a
53basic approach that is feasible to get working within a relatively short
57==== UNIS/ABAC implementation for GEC15 ====
59We define two roles for each slice that UNIS tracks:
61 - slice_admin (rSA)
62 - slice_owner (rSO)
64The UNIS service is the principal that creates and maintains these roles using
65libabac.  A keystore is maintained that stores the identity and attribute
66certificates as they are generated.  These are actual files written to disk.
68For a given slice, the first step in the role creation process is when the
69bootstrapper pushes (HTTP POST) the slice credential (along with user cert) to
70UNIS.  The following attributes are generated:
72 1. UNIS.rSO <- user
73This says the UNIS server principle has a role slice_owner (rSO) and the user is
74a slice owner.
76 2. UNIS.rSA <- UNIS.rSO
77This says all slice owners are slice admins.  Allows the user to present their
78own cert when asking for slice admin access.
80 3. UNIS.rSA <- UNIS.rSO.rSA
81This says anyone who has the slice owner attribute can delegate slice admin to
82another entity, an example of a linked role.
84NOTE: because we are using RT0, these attributes need to be generated for every
85slice credential that gets posted.  RT2 allows for parameterized objects and
86could make this more robust, but it's also more complicated and I'm still trying
87to get my head around it.  RT0 is sufficient for an initial implementation.
89At this point, the keystore contains 4 new entries: 3 attribute files, one for
90each described above, and the user certificate.  The roles defined have a
91lifespan equal to the slice lifetime, matching what is learned from the slice
94It is easy to imagine additional roles being defined.  Perhaps a read_only (rRO)
97 1. UNIS.rRO <- UNIS.rSO
98All slice owners are also read only users.
100 2. UNIS.rRO <- UNIS.rSO.rRO
101This says slice owners can delegate read only attributes to other entities.
103Now the user could give some proxy certs read only access instead of slice admin
104access, for example.  Defining how many roles we need and how they are managed
105will require a broader discussion, and this may be obviated if we defer to a
106global policy store.
108Now that the roles for the given slice are defined in UNIS, the bootsrap process
109can assign attributes to the service proxy certs we generated earlier.
111Creddy is used to assign attributes:
113$ creddy --attribute --issuer user.pem --key user.key --role slice_admin \
114  --subject-cert blipp_service_ID.pem --out blipp_service_proxy_attr.der
116The .der file now defines the following attribute:
118user.rSA <- blipp_service_ID
120What's stored in the file is binary but is represented similar to this:
122$ creddy --roles --cert blipp_service_proxy_attr.der
125Because we setup the delegation attribute earlier, UNIS can now say that the
126BLiPP service has slice admin access because user, who gave the attribute to
127BLiPP, is a slice owner.  In a similar fashion, the slice owner could also
128delegate slice admin to another user's cert.
130The bootstrap process needs to send (HTTP POST) these credentials to UNIS so
131they can be added to the keystore.  The new attributes are loaded into the
132running ABAC context.  Requests for resources using delegated proxy or user
133certs are now checked against this set of attributes. The ABAC resolver will run
134queries based on the required level of access.  For GEC15, the primary check
135will ask: is slice admin access granted? If so return resource (e.g., topology,
136metadata), if not, return error.
139==== General Usage Notes ====
1411. All communication to UNIS is over an SSL socket.  The server requires a valid
142user certificate and checks the issuer against the GENI CA bundle.  If a client
143or service uses a certificate signed by a non-GENI CA, the request will be
144rejected outright.
147==== Outstanding Issues ====
1491. Proxy certs are not currently being accepted by creddy in 0.2.2.  ABAC dev
150team is looking into problem.  We have tested delegating roles to non-proxy
151certs, which does work.
1532. Current libabac implementation is designed to work with self-signed certs
154only, for no apparent reason.  libabac code has been modified (read hacked) to
155accept CA-signed certs.  ABAC dev team is also aware and looking into solutions.
158==== Current Status ====
160Proof of concept from Guilherme (client/server) code updated to ABAC 0.2.2.  Key
161functionality as described above is working.  In-progress tasks include
162completing HTTPS interface for accepting slice and ABAC credentials and
163integrating completed code into existing UNIS service.  The plan is to have a
164test instance up and running so others can experiment by pushing their own slice
165credentials and attributes.
168==== 9/28 UPDATES ====
1701. Worked with ABAC team to allow the use of certs other than self-signed certs.
171Issue was with how they were verifying signatures. These changes are making
172their way into the next ABAC release.
1742. Email exchange with ABAC team about supporting proxy certificates. libabac
175uses to handle certificates, which apparently doesn't
176recognize x.509 proxy extensions in current releases.  It's possible to disable
177the strongswan check for critical extensions, and this works fine from the
178perspective of ABAC, but it's not an ideal solution. 
1803. Now that key technical issues with ABAC are addressed, I have been
181integrating this AA model into UNIS and the bootstrap process.  UNIS has
182endpoints for registering the slice credential and adding ABAC credentials.
183AuthZ checks are made on the basis of whether the UNIS resource is associated
184with a given slice and if the ABAC query says that the presented user cert has
185access to the slice.
188==== 9/28 NOTES ====
190One of Jim's points was that ABAC doesn't really care about who signed the
191certificates, if they they are proxied, etc.  and we could make things simpler
192with services generating their own certs. That's completely valid, and ABAC does
193only care about generating proof graphs using identities and the given
194attributes.  However, the ABAC implementation itself (libabac) has
195responsibility for deciding how to verify the x.509 certificates used to build
196those identities and attributes.  As I noted above, the 0.2.2 libabac
197implementation only accepted self-signed certs when I started on this, which I
198really didn't understand, and the ISI ABAC team was happy to fix their
199verification methods.
201My point is, ABAC is one thing, how we deal with certificates and chain of trust
202in GEMINI AA is another.  For example, the GEMINI services we are building are
203accessed via SSL/TLS, and this includes the existing LAMP portal and old UNIS.
204To even establish a secure connection, we currently require that the client
205(i.e. "user") certificate be signed by a trusted authority.  The service
206verifies the user cert against a CA store, or "genica.bundle", that you can pull
207from a clearing house like  At this level, this has nothing to
208do with ABAC.
210One of the main reasons proxy certificates came up, is that you can't do the
211above check with self-signed certificates unless you add every new "issuer" (the
212self-signer) cert to the CA store.  With a proxy cert, the service verifies that
213the proxy cert was signed by the GENI user cert, which was in turn signed by a
214trusted root (e.g. Utah).
216Of course, this is not the only way to do things.  We could have our SSL/TLS
217services in GEMINI accept any certificate, no matter who signed it, and let ABAC
218figure out if it's valid or not for a particular GEMINI role.  I think this
219would work as well, but the caveat is we would not have a way to verify who
220those certs are really identifying since they would not be signed by an
221authority.  A middle-ground approach could introduce a GEMINI CA for signing
222service certs used in our workflow.
224What we don't get from the above approaches is the services acting on behalf of
225the slice owner who created the experiment, the service certs would only mean
226something to ABAC.  You can't have a service with its auto-generated cert say to
227another service outside of GEMINI "you can trust me, I'm really Harry making
228this request" because there's no chain of trust outside of what's defined in
229GEMINI ABAC.  The real question is, do we need to make those kinds of requests?
230My current answer is: maybe this is not required because no other external
231service will even accept proxy certs at the moment, but why not do it and have
232that flexibility if we can.