Slice credentials are not checked when executing listresources on a sliver

[lnevers@bbn.com]

Problem scenario:

A user creates two slices with one sliver in each, then downloads the slice credentials for the first slice, and then executes a ListResources? on the second slice. It seems that the slice credentials are not checked, because the credentials for the second slice can be successfully used to execute a listresources for the first slice.

Following is a capture:

$ omni.py -a exobbn getslicecred lnslice1 -o
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnslice1 expires on 2012-07-27 16:52:04 UTC
INFO:omni:Retrieved slice cred for slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnslice1
INFO:omni:Wrote slice lnslice1 credential to file 'lnslice1-cred.xml'
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed getslicecred:

  Options as run:
		aggregate: exobbn
		framework: pgeni
		native: True
		output: True

  Args: getslicecred lnslice1

  Result Summary: Saved slice lnslice1 cred to file lnslice1-cred.xml 
INFO:omni: ============================================================

$ omni.py -a exobbn listresources lnslice2 --slicecredfile ./lnslice1-cred.xml -o 
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
INFO:omni:Saving output to a file.
INFO:omni:Getting slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+lnslice2 credential from file ./lnslice1-cred.xml
INFO:omni:Gathering resources reserved for slice lnslice2.
INFO:omni:Substituting AM nickname exobbn with URL https://bbn-hn.exogeni.net:11443/orca/xmlrpc, URN unspecified_AM_URN
INFO:omni:Listed resources on 1 out of 1 possible aggregates.
INFO:omni:Writing to 'lnslice2-rspec-bbn-hn-exogeni-net-11443-orca.xml'
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed listresources:

  Options as run:
		aggregate: exobbn
		framework: pgeni
		native: True
		output: True
		slicecredfile: ./lnslice1-cred.xml

  Args: listresources lnslice2

  Result Summary: Retrieved resources for slice lnslice2 from 1 aggregates.
Wrote rspecs from 1 aggregates to 1 files
Saved listresources RSpec at 'unspecified_AM_URN' to file lnslice2-rspec-bbn-hn-exogeni-net-11443-orca.xml; . 
INFO:omni: ============================================================

Also tried the other AM API functions:"sliverstatus", "deletesliver", "createsliver", and "renewsliver"; each of these function does check the credentials and fail as expected:

Credendial Exception: javax.security.auth.login.CredentialException: No credential was found with appropriate privileges.

[lnevers@bbn.com]

Also tested this scenario with two different user accounts (​lnevers@bbn.com and ​lnevers1@bbn.com). As ​lnevers1@bbn.com checked access to sliver AM API functions with other user ​lnevers@bbn.com credentials. The following commands were tried and failed as expected:

lnevers1@sendaria$ omni.py -a exobbn listresources lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 

lnevers1@sendaria$ omni.py -a exobbn sliverstatus lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 

lnevers1@sendaria$ omni.py  -a exobbn renewsliver lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 2012-07-28

lnevers1@sendaria$ omni.py -a exobbn shutdown lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 

lnevers1@sendaria$ omni.py -a exobbn deletesliver lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 

lnevers1@sendaria$ omni.py -a exobbn createsliver lnevers-slice --slicecredfile ./lnevers-slice-cred.xml ./exo-2vm-1lan.rspec 

[ibaldin@renci.org]

That's a feature, not a bug. We allow users to list. You should not however be able to do anything else (like delete the slice).

[ahelsing@bbn.com]

Ilia: Sorry for the delay - we've been looking hard at the API and testing your implementation of it. You've seen the added bug #86 and #87 as a result. We're still doing tests.

We believe this is in fact a bug. Users must supply a valid slice credential to operate on a slice, even listresources. Arguably the documentation is not clear (and we've tried to improve it for AM API v3), but this violates the intent of the API.

The API requires that operations on a slice include a valid credential whose target grants permissions on that slice. We believe you are not enforcing this consistently. AM-local knowledge of who created the slivers is not supposed to trump the provided credentials.

So listresources must take a valid slice credential for this slice and this user - not a different slice credential or a user credential.

For the relevant sections of the API, see: ​http://groups.geni.net/geni/wiki/GAPI_AM_API_V2_DETAILS#credentialsArgument "At least one credential must be a valid slice credential for the slice specified in slice_urn if that is an argument .... Credentials must be valid ( ... and grant privileges to the client identified by the SSL client certificate)."

(See also ​http://groups.geni.net/geni/wiki/GeniApiCredentials)

There are 5 elements to consider:

1. User who created the slivers at this AM
2. Client user (identified by the SSL client certificate)
3. Credential owner (Owner GID: user in the slice credential)
4. Credential target (Target GID: slice in a slice credential, user in a user credential)
5. Slice URN (slice you are trying to operate on).

The quote from the API spec above tells me that:

1. 4 must be = 5. Credential target must identify the same slice as the slice URN. If you are operating on a slice, then you must provide a credential granting permissions on that slice - not on the user, and not on another slice. We believe that you are not enforcing this consistently. Hence this ticket (and others).
2. 2 must be = 3. SSL Client certificate must match the Credential Owner GID. The provided credential must grant rights to the caller. Not to another user over the same slice, but to you. We believe you are correctly enforcing this.

[jaipuria@cs.duke.edu]

Fixed.

[lnevers@bbn.com]

Problen resolution verified, the listresources now also check the slice credentials. Problem is addressed, closing ticket.