1. 28 May, 2013 1 commit
    • Leigh Stoller's avatar
      Reorg the credential checking code, and add Geni chain checks. · dd5c6601
      Leigh Stoller authored
      From: Leigh Stoller <lbstoller@gmail.com>
      Date: Wed, 22 May 2013 13:49:33 -0700
      Cc: instageni-design@geni.net
      So far we have been pretty loose about checking to make sure the
      certificate chains obey the Geni rules. These rules include checking to
      make sure that only approved entities can sign particular kinds of
      credentials. For example; only something known to be a Slice Authority
      should be allowed to create a slice and return a slice credential.
      The other check we have been lax about, is verifying that the URN namespace
      is consistent along the chain from CA to the target. For example, a chain
      that starts in Utah:
      should not be able to sign anything outside its namespace. That is, Utah
      should not be able to sign a user or slice credential like:
      This is made more complicated when we introduce subsa certs along the way,
      where Utah signs its SA cert and that signs a project slice. In this case
      the chain would look something like:
      There are also scoping rules; A subsa like:
      should not be able to sign:
      The entire cert chain is require to verify this. The CA roots are in the
      bundle, and the intermediate certs should be enclosed in the signature
      section of the XML document.
      We have to make the same check against the user certificate after apache
      verifies the chain. For apache (or any SSL server) you have to load the
      chain, and as I mentioned in earlier email, this is easy with perl and
      python based clients.
      With all that said, we do not plan to start rigorous enforcement of the
      first check above, and for the second class of checks, we just want to
      enforce a simple prefix check until we get our subsa house in order (since
      we don't even conform properly yet!).
  2. 24 Jan, 2013 1 commit
  3. 23 Jan, 2013 2 commits
  4. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      This commit is intended to clear up that confusion.
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
  5. 06 Jul, 2012 1 commit
  6. 03 Jul, 2012 1 commit
  7. 12 Jun, 2012 1 commit
    • Leigh Stoller's avatar
      Minor change to credential verification and load. · f3310749
      Leigh Stoller authored
      Move the expiration test into verifygenicred. Change the invocation to
      capture the output so that we can say something useful in the error
      response, instead of what we do now which is just tell the user there
      is an error.
  8. 25 Apr, 2012 1 commit
    • Leigh Stoller's avatar
      Add ReadHistoryRecords() API to download the aggregate history · d3c74dc7
      Leigh Stoller authored
      from the CH database.
      Requires a credential (possibly delegated) with the "readhistory"
         ReadHistoryRecords(credential, int index, int count);
      where index and count are optional, but to be useful you will want to
      track the index and ask for "count" records at a time until you get
      back an error saying there are no more to give you. You are limited to
      max 100 (the default is 10) time at a time.
      The return value is a list of records, where each record is an array
      of the data in the aggregate_history table and the manifest. There
      might be multiple records if the slice was updated, since there will
      be multiple manifests. I won't describe it, you can just print out a
      record and see it, it is all pretty obvious.
  9. 13 Apr, 2012 1 commit
  10. 11 Apr, 2012 1 commit
  11. 06 Apr, 2012 1 commit
  12. 05 Apr, 2012 1 commit
    • Leigh Stoller's avatar
      Bug Fix: The other part of the aggregate history changes that need to · 1ea5bf13
      Leigh Stoller authored
      go in before Monday. Once a CM updates to stable, it will start
      sending aggregate/manifest history records to the ClearingHouse, which
      will store all records for all CMs. The CM actually goes back and sends
      all the records from the beginning of time; hopefully there will not
      be any serious problems with the very early records at the early CMs.
      Still to be done, is an interface at the CH to export the records to
      someone with a proper credential. But that can wait till next week.
  13. 15 Feb, 2012 1 commit
  14. 07 Nov, 2011 1 commit
  15. 21 Jul, 2011 1 commit
  16. 15 Jun, 2011 1 commit
  17. 13 Jun, 2011 1 commit
  18. 20 Apr, 2011 1 commit
    • Leigh Stoller's avatar
      Changes our ssh key/account handling in RedeemTicket() and · 03c2107c
      Leigh Stoller authored
      CreateSliver(), to handle multiple accounts.  This somewhat reflects
      the Geni AM API for keys, which allows the client to specify multiple
      users, each with a set of ssh keys.
      The keys argument to the CM now looks like the following (note that
      the old format is still accepted and will be for a while).
      [{'urn'   => 'urn:blabla'
        'login' => 'dopey',
        'keys'  => [ list of keys like before ]},
       {'login' => "leebee",
        'keys'  => [ list of keys ... ]}];
      Key Points:
      1. You can supply a urn or a login or both. Typically, it is going to
         be the result of getkeys() at the PG SA, and so it will include
      2. If a login is provided, use that. Otherwise use the id from the urn.
      3. No matter what, verify that the token is valid for Emulab an uid
         (standard 8 char unix login that is good on just about any unix
         variant), and transform it if not.
      4. For now, getkeys() at the SA will continue to return the old format
         (unless you supply version=2 argument) since we do not want to
         default to a keylist that most CMs will barf on.
      5. I have modified the AM code to transform the Geni AM version of the
         "users" argument into the above structure. Bottom line here, is
         that users of the AM interface will not actually need to do
         anything, although now multiple users are actually supported
         instead of ignored.
      Still to be done are the changes to the login services structure in
      the manifest. We have yet to settle on what these changes will look
      like, but since people generally supply valid login ids, you probably
      will not need this, since no transformation will take place.
  19. 07 Apr, 2011 1 commit
  20. 06 Apr, 2011 1 commit
  21. 24 Mar, 2011 1 commit
  22. 06 Jan, 2011 1 commit
  23. 12 Nov, 2010 1 commit
  24. 29 Sep, 2010 1 commit
  25. 26 Apr, 2010 1 commit
  26. 03 Feb, 2010 1 commit
    • Leigh Stoller's avatar
      Couple of little fixes; · 2424c7fc
      Leigh Stoller authored
      * When resolving a component, return the gif (certificate) of the
        authority it belongs to.
      * Quick fix for skiping links that are for another CM. This will
        change later when the schema defines it.
  27. 25 Jan, 2010 1 commit
  28. 06 Jan, 2010 2 commits
    • Leigh Stoller's avatar
      Minor fix. · b11f7ab4
      Leigh Stoller authored
    • Leigh Stoller's avatar
      Slice expiration changes. The crux of these changes: · 5c63cf86
      Leigh Stoller authored
      1. You cannot unregister a slice at the SA before it has expired. This
         will be annoying at times, but the alphanumeric namespace for slice
         ames is probably big enough for us.
      2. To renew a slice, the easiest approach is to call the Renew method
         at the SA, get a new credential for the slice, and then pass that
         to renew on the CMs where you have slivers.
      The changes address the problem of slice expiration.  Before this
      change, when registering a slice at the Slice Authority, there was no
      way to give it an expiration time. The SA just assigns a default
      (currently one hour). Then when asking for a ticket at a CM, you can
      specify a "valid_until" field in the rspec, which becomes the sliver
      expiration time at that CM. You can later (before it expires) "renew"
      the sliver, extending the time. Both the sliver and the slice will
      expire from the CM at that time.
      Further complicating things is that credentials also have an
      expiration time in them so that credentials are not valid forever. A
      slice credential picks up the expiration time that the SA assigned to
      the slice (mentioned in the first paragraph).
      A problem is that this arrangement allows you to extend the expiration
      of a sliver past the expiration of the slice that is recorded at the
      SA. This makes it impossible to expire slice records at the SA since
      if we did, and there were outstanding slivers, you could get into a
      situation where you would have no ability to access those slivers. (an
      admin person can always kill off the sliver).
      Remember, the SA cannot know for sure if there are any slivers out
      there, especially if they can exist past the expiration of the slice.
      The solution:
      * Provide a Renew call at the SA to update the slice expiration time.
        Also allow for an expiration time in the Register() call.
        The SA will need to abide by these three rules:
        1. Never issue slice credentials which expire later than the
           corresponding slice
        2. Never allow the slice expiration time to be moved earlier
        3. Never deregister slices before they expire [*].
      * Change the CM to not set the expiration of a sliver past the
        expiration of the slice credential; the credential expiration is an
        upper bound on the valid_until field of the rspec. Instead, one must
        first extend the slice at the SA, get a new slice credential, and
        use that to extend the sliver at the CM.
      * For consistency with the SA, the CM API will changed so that
        RenewSliver() becomes RenewSlice(), and it will require the
        slice credential.
  29. 22 Dec, 2009 1 commit
  30. 30 Oct, 2009 1 commit
  31. 26 Aug, 2009 1 commit
  32. 10 Aug, 2009 1 commit
  33. 28 Jul, 2009 1 commit
  34. 27 Jul, 2009 1 commit
  35. 17 Jul, 2009 1 commit
  36. 16 Jul, 2009 1 commit
  37. 13 Jul, 2009 2 commits