Changes between Initial Version and Version 1 of orca_security_enhancements

Show
Ignore:
Timestamp:
11/24/08 11:28:44 (11 years ago)
Author:
ibaldin (IP: 152.54.9.131)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • orca_security_enhancements

    v1 v1  
     1== Orca/Shirako Security, and Steps for GENI-Orca == 
     2 
     3Authentication and authorization are based on digitally signed 
     4messages (WS-Security) and the Java Cryptography Architecture (e.g., 
     5keystore files). 
     6 
     7Every actor is named by a GUID.  Every actor possesses a keypair for 
     8authentication.  Each actor has access to a registry of the GUIDs and 
     9public keys of other actors that are known to it.  Actors sign their 
     10messages with their private keys, and authenticate messages based on 
     11their knowledge of the sender's public key.  We use the term 
     12"principal" to refer to an identity bound to a public key.  [Note that 
     13a principal could wield multiple public keys.] 
     14 
     15Each actor runs within a container, which also has a keypair and GUID. 
     16A container administrator (owner) can control the actors within the 
     17container. 
     18 
     19An actor's keypair and key registry comprise its "security 
     20configuration".  The security configuration files reside in the 
     21"runtime directory" of the actor's container.  The file names are 
     22derived from the actor's GUID, so the files persist and can be 
     23retrieved by GUID.  Most aspects of security configuration are fully 
     24automated, but there are also manual tools available for a container 
     25owner to generate, view, and edit security configurations. 
     26 
     27Each actor assigns some level of trust to other actors/principals on 
     28the basis of public key.  Actors learn of public keys and assign trust 
     29to them in at least two ways.  First, a container owner can use the 
     30configuration tools to register principals (public keys) for various 
     31levels of trust and access with the actors in a container.  For 
     32example, a broker operator might register public keys of guests 
     33(service managers to be precise) that are authorized to request 
     34resources from that broker.  Second, actors may assign trust to a 
     35principal based on an endorsement of its public key from some other 
     36actor.  For example, a ticket issued by a broker endorses the public 
     37key of a guest to an authority. 
     38 
     39The actor's GUID and keypair are typically generated automatically 
     40when the actor is created.  The code that instantiates an actor and 
     41binds it to a GUID and keypair is part of the "boot" code.  The boot 
     42code runs to populate a freshly instantiated container with actors 
     43specified in a container configuration file.  The same code also runs 
     44when an actor is created dynamically, e.g., through the Web portal. 
     45 
     46For more control, a container owner may use the tools to generate the 
     47GUID and security configuration by hand in advance.  In this case the 
     48configuration file or portal request may specify a GUID.  [Note/Q: is 
     49it possible to hardwire an actor's public key, and install its private 
     50key in its security configuration.] 
     51 
     52=== Implementation === 
     53 
     54The current implementation uses Rampart/Axis2 for authenticated 
     55communication over SOAP.  An actor's security configuration also 
     56includes an Axis2 configuration file that determines which signing 
     57keys to use for SOAP messages sent by that actor. 
     58 
     59The implementation stores the key registry in a Java keystore file 
     60(jks) for the actor.  The keystore is encrypted with a password; a 
     61common password is hardwired into the source code to enable 
     62programmatic use. 
     63 
     64Rampart assumes use of a PKI and is awkward to use with a 
     65decentralized trust management architecture, as in Orca.  The Rampart 
     66code is based on certificate manipulation, rather than public key 
     67manipulation.  Public keys are certified by certificates, and there is 
     68no means to register a public key for access without an accompanying 
     69certificate.  This makes it difficult for actors to endorse keys, and 
     70for other actors to assign trust on the basis of such endorsements. 
     71Rampart presumes that certificates are endorsed by designated 
     72certifying authorities within a PKI hierarchy.  The current 
     73Rampart-based Orca implementation uses self-signed certificates, and 
     74thus is insecure (see below). 
     75 
     76When an actor receives a request, the message receive proxy obtains a 
     77reference to an !AuthToken object that represents the identity of the 
     78requester.  The requester is authenticated by means of the public key 
     79associated with the signed request.  The !AuthToken of the requester is 
     80available to the request-handling code for the access control policy. 
     81The request handling code upcalls an "auth" module that implements the 
     82access control policy for the requesting principal (subject), the 
     83object to be operated on, and the type of operation.  The current 
     84implementation uses the "null" access control policy (just say yes). 
     85 
     86=== Task List === 
     87 
     88Desired functions for security additions to Orca/Shirako "auth" code 
     89and related code. 
     90 
     91 * Each actor must maintain a set of known principals and a property 
     92list of security attributes for each known principal.  This 
     93corresponds to the GENI "principal registry".  The keystore in the 
     94security configuration currently may be (almost) sufficient, but we 
     95need to be sure we can associate an incoming request with a principal 
     96that is known to the actor persistently, and pass along security 
     97attributes for that principal with the !AuthToken so they are 
     98accessible to the request handling code.  We also need an interface 
     99for the request handling code to make entries in this principal 
     100registry.  Principal registry entries could also be installed by the 
     101actor operator, i.e., through the portal or command line tools. 
     102 
     103 * For each slice and reservation, at each broker and authority, enable 
     104access for the identity that created the slice and reservation.  Save 
     105the creator's identity, and check for a match on subsequent operations 
     106on the slice or reservation.  Allow the container owner to override 
     107(e.g., to change the owning identity) through the Web portal. 
     108 
     109 * For each slice and reservation, at each broker and authority, enable 
     110access for principals bearing the "root" security attribute.  These 
     111"root" identities correspond to GENI operations or some other 
     112controlling authority. 
     113 
     114 * For each slice and reservation, at each broker and authority, 
     115disable unauthorized access (i.e., not the owner and not root). 
     116 
     117 * At each broker, enable ticket requests from recognized principals 
     118that are authorized to submit them, as determined by a security 
     119attribute for the principal.  These endorsing principals are called 
     120"identity providers". 
     121 
     122 * At each broker, enable ticket requests from some principal that is 
     123endorsed by an entity that is authorized to endorse ticket requesters, 
     124as determined by a security attribute for the endorsing principal. 
     125Note: this means that the auth checking code must have access to the 
     126endorsement chain, as well as the requester AuthToken itself. 
     127 
     128 * At each broker, disable ticket requests from unauthorized principals 
     129(i.e., not recognized or authorized as a guest, not endorsed by a 
     130trusted identity provider). 
     131 
     132 * For each authority, allow the container owner to install a list of 
     133trusted broker principals and to command delegations of inventory 
     134resources to those brokers. 
     135 
     136 * For each authority, validate redeemed tickets as coming from a 
     137one-hop trusted broker (later more complete ticket validation).  This 
     138validation could occur through the standard SHARP ticket validation 
     139code, or it could be a check of a security attribute associated with 
     140the ticket endorsee. 
     141 
     142 * At each broker, on initial request of a new slice, assign a GUID to 
     143the slice, and attach a slice property whose value is an X.509 cert 
     144containing the requesting guest's public key and the slice GUID.  The 
     145guest controller should use this GUID as the GUID of the slice, rather 
     146than a GUID that it creates itself.  The guest controller should pass 
     147the slice certification property through on all ticket and redeem 
     148requests for this slice.  Brokers and authorities should check the 
     149certification when they first learn of a slice, and save it with the 
     150slice.  [Note: this is not a required function, it simply provides 
     151compliance with the GENI CFA notion of a "slice authority".] 
     152 
     153 * Within the Web portal, when an authorized user creates an actor, 
     154mint a keypair for the actor, and create an X.509 certificate signed 
     155by the container and endorsing the public key of the new actor as 
     156bound to the principal of the requesting user.  This enables the 
     157container to act as an identity provider.  As a first cut, all users 
     158will issue their requests through Web portals that are bound to 
     159containers that are trusted as registered identity providers by the 
     160Clearinghouse (broker). 
     161 
     162