== GEMINI AA Planning == 101112 This document provides details on the AA workflow diagram created by Guilherme. Refer to AA-workflow.png. The proposed model remains relatively unchanged from the diagram. The following discussion assumes a UNIS implementation using ABAC 0.2.2, the current stable release from ISI. ==== BOOTSTRAP PROCESS ==== In the context of GENI, the basis for authentication and authorization to an I&M service (e.g., UNIS) is the user certificate and private key. These certificates (cert) are obtained from a trust authority, e.g., Utah or the GPO. - user.pem - user.key For each service that interacts within the I&M system, we want to generate a identity (key pair) to provide access control via proxy certs. Our original approach in LAMP generated a dedicated lampcert for this purpose, which allowed for unrestricted access between services. A proxy cert per service will eventually allow the user (i.e., slice owner) to delegate access to I&M services at different granularities. The proxy certs are signed by the user cert, meaning a proxy cert is validated against the service as if the request was made by the user. However, attributes that are assigned to the service identity can restrict authorized use for each proxy cert. Example of how to create service identity and proxy certificates: $ openssl req -new -config csr.conf -out blipp_service.csr -keyout blipp_service.key $ openssl x509 -req -CAcreateserial -in blipp_service.csr -days 365 \ -out blipp_service_ID.pem -CA user.pem -CAkey user.key \ -extfile csr.conf -extensions v3_proxy We now have a service proxy cert: - blipp_service_ID.pem The proxy cert is concatenated with the user cert to maintain the chain of trust and is pushed to the service nodes. The service now uses this proxy cert to ask for resources on a service like UNIS. Now that we have proxy certs per service, we need to create ABAC credentials. We use the slice credential to effectively associate the user with the experiment slice when defining ABAC roles and to determine the lifetime (up to slice expiration time) of said roles. While there are a number of ways to create and maintain attributes and policies, the following section outlines a basic approach that is feasible to get working within a relatively short timeframe. ==== UNIS/ABAC implementation for GEC15 ==== We define two roles for each slice that UNIS tracks: - slice_admin (rSA) - slice_owner (rSO) The UNIS service is the principal that creates and maintains these roles using libabac. A keystore is maintained that stores the identity and attribute certificates as they are generated. These are actual files written to disk. For a given slice, the first step in the role creation process is when the bootstrapper pushes (HTTP POST) the slice credential (along with user cert) to UNIS. The following attributes are generated: 1. UNIS.rSO <- user This says the UNIS server principle has a role slice_owner (rSO) and the user is a slice owner. 2. UNIS.rSA <- UNIS.rSO This says all slice owners are slice admins. Allows the user to present their own cert when asking for slice admin access. 3. UNIS.rSA <- UNIS.rSO.rSA This says anyone who has the slice owner attribute can delegate slice admin to another entity, an example of a linked role. NOTE: because we are using RT0, these attributes need to be generated for every slice credential that gets posted. RT2 allows for parameterized objects and could make this more robust, but it's also more complicated and I'm still trying to get my head around it. RT0 is sufficient for an initial implementation. At this point, the keystore contains 4 new entries: 3 attribute files, one for each described above, and the user certificate. The roles defined have a lifespan equal to the slice lifetime, matching what is learned from the slice credential. It is easy to imagine additional roles being defined. Perhaps a read_only (rRO) role: 1. UNIS.rRO <- UNIS.rSO All slice owners are also read only users. 2. UNIS.rRO <- UNIS.rSO.rRO This says slice owners can delegate read only attributes to other entities. Now the user could give some proxy certs read only access instead of slice admin access, for example. Defining how many roles we need and how they are managed will require a broader discussion, and this may be obviated if we defer to a global policy store. Now that the roles for the given slice are defined in UNIS, the bootsrap process can assign attributes to the service proxy certs we generated earlier. Creddy is used to assign attributes: $ creddy --attribute --issuer user.pem --key user.key --role slice_admin \ --subject-cert blipp_service_ID.pem --out blipp_service_proxy_attr.der The .der file now defines the following attribute: user.rSA <- blipp_service_ID What's stored in the file is binary but is represented similar to this: $ creddy --roles --cert blipp_service_proxy_attr.der [keyid:62d12b0dcd5a8a9c3bddb175c8033506bb72a8e4].role:slice_admin_for_<-[keyid:22f6c982dfaadd9a1ef27d27a5e3ff75e511bf80] Because we setup the delegation attribute earlier, UNIS can now say that the BLiPP service has slice admin access because user, who gave the attribute to BLiPP, is a slice owner. In a similar fashion, the slice owner could also delegate slice admin to another user's cert. The bootstrap process needs to send (HTTP POST) these credentials to UNIS so they can be added to the keystore. The new attributes are loaded into the running ABAC context. Requests for resources using delegated proxy or user certs are now checked against this set of attributes. The ABAC resolver will run queries based on the required level of access. For GEC15, the primary check will ask: is slice admin access granted? If so return resource (e.g., topology, metadata), if not, return error. ==== General Usage Notes ==== 1. All communication to UNIS is over an SSL socket. The server requires a valid user certificate and checks the issuer against the GENI CA bundle. If a client or service uses a certificate signed by a non-GENI CA, the request will be rejected outright. ==== Outstanding Issues ==== 1. Proxy certs are not currently being accepted by creddy in 0.2.2. ABAC dev team is looking into problem. We have tested delegating roles to non-proxy certs, which does work. 2. Current libabac implementation is designed to work with self-signed certs only, for no apparent reason. libabac code has been modified (read hacked) to accept CA-signed certs. ABAC dev team is also aware and looking into solutions. ==== Current Status ==== Proof of concept from Guilherme (client/server) code updated to ABAC 0.2.2. Key functionality as described above is working. In-progress tasks include completing HTTPS interface for accepting slice and ABAC credentials and integrating completed code into existing UNIS service. The plan is to have a test instance up and running so others can experiment by pushing their own slice credentials and attributes. ==== 9/28 UPDATES ==== 1. Worked with ABAC team to allow the use of certs other than self-signed certs. Issue was with how they were verifying signatures. These changes are making their way into the next ABAC release. 2. Email exchange with ABAC team about supporting proxy certificates. libabac uses http://www.strongswan.org/ to handle certificates, which apparently doesn't recognize x.509 proxy extensions in current releases. It's possible to disable the strongswan check for critical extensions, and this works fine from the perspective of ABAC, but it's not an ideal solution. 3. Now that key technical issues with ABAC are addressed, I have been integrating this AA model into UNIS and the bootstrap process. UNIS has endpoints for registering the slice credential and adding ABAC credentials. AuthZ checks are made on the basis of whether the UNIS resource is associated with a given slice and if the ABAC query says that the presented user cert has access to the slice. ==== 9/28 NOTES ==== One of Jim's points was that ABAC doesn't really care about who signed the certificates, if they they are proxied, etc. and we could make things simpler with services generating their own certs. That's completely valid, and ABAC does only care about generating proof graphs using identities and the given attributes. However, the ABAC implementation itself (libabac) has responsibility for deciding how to verify the x.509 certificates used to build those identities and attributes. As I noted above, the 0.2.2 libabac implementation only accepted self-signed certs when I started on this, which I really didn't understand, and the ISI ABAC team was happy to fix their verification methods. My point is, ABAC is one thing, how we deal with certificates and chain of trust in GEMINI AA is another. For example, the GEMINI services we are building are accessed via SSL/TLS, and this includes the existing LAMP portal and old UNIS. To even establish a secure connection, we currently require that the client (i.e. "user") certificate be signed by a trusted authority. The service verifies the user cert against a CA store, or "genica.bundle", that you can pull from a clearing house like boss.emulab.net. At this level, this has nothing to do with ABAC. One of the main reasons proxy certificates came up, is that you can't do the above check with self-signed certificates unless you add every new "issuer" (the self-signer) cert to the CA store. With a proxy cert, the service verifies that the proxy cert was signed by the GENI user cert, which was in turn signed by a trusted root (e.g. Utah). Of course, this is not the only way to do things. We could have our SSL/TLS services in GEMINI accept any certificate, no matter who signed it, and let ABAC figure out if it's valid or not for a particular GEMINI role. I think this would work as well, but the caveat is we would not have a way to verify who those certs are really identifying since they would not be signed by an authority. A middle-ground approach could introduce a GEMINI CA for signing service certs used in our workflow. What we don't get from the above approaches is the services acting on behalf of the slice owner who created the experiment, the service certs would only mean something to ABAC. You can't have a service with its auto-generated cert say to another service outside of GEMINI "you can trust me, I'm really Harry making this request" because there's no chain of trust outside of what's defined in GEMINI ABAC. The real question is, do we need to make those kinds of requests? My current answer is: maybe this is not required because no other external service will even accept proxy certs at the moment, but why not do it and have that flexibility if we can.