Version 1 (modified by ibaldin, 11 years ago)

--

Orca/Shirako Security, and Steps for GENI-Orca

Authentication and authorization are based on digitally signed messages (WS-Security) and the Java Cryptography Architecture (e.g., keystore files).

Every actor is named by a GUID. Every actor possesses a keypair for authentication. Each actor has access to a registry of the GUIDs and public keys of other actors that are known to it. Actors sign their messages with their private keys, and authenticate messages based on their knowledge of the sender's public key. We use the term "principal" to refer to an identity bound to a public key. [Note that a principal could wield multiple public keys.]

Each actor runs within a container, which also has a keypair and GUID. A container administrator (owner) can control the actors within the container.

An actor's keypair and key registry comprise its "security configuration". The security configuration files reside in the "runtime directory" of the actor's container. The file names are derived from the actor's GUID, so the files persist and can be retrieved by GUID. Most aspects of security configuration are fully automated, but there are also manual tools available for a container owner to generate, view, and edit security configurations.

Each actor assigns some level of trust to other actors/principals on the basis of public key. Actors learn of public keys and assign trust to them in at least two ways. First, a container owner can use the configuration tools to register principals (public keys) for various levels of trust and access with the actors in a container. For example, a broker operator might register public keys of guests (service managers to be precise) that are authorized to request resources from that broker. Second, actors may assign trust to a principal based on an endorsement of its public key from some other actor. For example, a ticket issued by a broker endorses the public key of a guest to an authority.

The actor's GUID and keypair are typically generated automatically when the actor is created. The code that instantiates an actor and binds it to a GUID and keypair is part of the "boot" code. The boot code runs to populate a freshly instantiated container with actors specified in a container configuration file. The same code also runs when an actor is created dynamically, e.g., through the Web portal.

For more control, a container owner may use the tools to generate the GUID and security configuration by hand in advance. In this case the configuration file or portal request may specify a GUID. [Note/Q: is it possible to hardwire an actor's public key, and install its private key in its security configuration.]

Implementation

The current implementation uses Rampart/Axis2 for authenticated communication over SOAP. An actor's security configuration also includes an Axis2 configuration file that determines which signing keys to use for SOAP messages sent by that actor.

The implementation stores the key registry in a Java keystore file (jks) for the actor. The keystore is encrypted with a password; a common password is hardwired into the source code to enable programmatic use.

Rampart assumes use of a PKI and is awkward to use with a decentralized trust management architecture, as in Orca. The Rampart code is based on certificate manipulation, rather than public key manipulation. Public keys are certified by certificates, and there is no means to register a public key for access without an accompanying certificate. This makes it difficult for actors to endorse keys, and for other actors to assign trust on the basis of such endorsements. Rampart presumes that certificates are endorsed by designated certifying authorities within a PKI hierarchy. The current Rampart-based Orca implementation uses self-signed certificates, and thus is insecure (see below).

When an actor receives a request, the message receive proxy obtains a reference to an AuthToken object that represents the identity of the requester. The requester is authenticated by means of the public key associated with the signed request. The AuthToken of the requester is available to the request-handling code for the access control policy. The request handling code upcalls an "auth" module that implements the access control policy for the requesting principal (subject), the object to be operated on, and the type of operation. The current implementation uses the "null" access control policy (just say yes).

Task List

Desired functions for security additions to Orca/Shirako "auth" code and related code.

  • Each actor must maintain a set of known principals and a property

list of security attributes for each known principal. This corresponds to the GENI "principal registry". The keystore in the security configuration currently may be (almost) sufficient, but we need to be sure we can associate an incoming request with a principal that is known to the actor persistently, and pass along security attributes for that principal with the AuthToken so they are accessible to the request handling code. We also need an interface for the request handling code to make entries in this principal registry. Principal registry entries could also be installed by the actor operator, i.e., through the portal or command line tools.

  • For each slice and reservation, at each broker and authority, enable

access for the identity that created the slice and reservation. Save the creator's identity, and check for a match on subsequent operations on the slice or reservation. Allow the container owner to override (e.g., to change the owning identity) through the Web portal.

  • For each slice and reservation, at each broker and authority, enable

access for principals bearing the "root" security attribute. These "root" identities correspond to GENI operations or some other controlling authority.

  • For each slice and reservation, at each broker and authority,

disable unauthorized access (i.e., not the owner and not root).

  • At each broker, enable ticket requests from recognized principals

that are authorized to submit them, as determined by a security attribute for the principal. These endorsing principals are called "identity providers".

  • At each broker, enable ticket requests from some principal that is

endorsed by an entity that is authorized to endorse ticket requesters, as determined by a security attribute for the endorsing principal. Note: this means that the auth checking code must have access to the endorsement chain, as well as the requester AuthToken? itself.

  • At each broker, disable ticket requests from unauthorized principals

(i.e., not recognized or authorized as a guest, not endorsed by a trusted identity provider).

  • For each authority, allow the container owner to install a list of

trusted broker principals and to command delegations of inventory resources to those brokers.

  • For each authority, validate redeemed tickets as coming from a

one-hop trusted broker (later more complete ticket validation). This validation could occur through the standard SHARP ticket validation code, or it could be a check of a security attribute associated with the ticket endorsee.

  • At each broker, on initial request of a new slice, assign a GUID to

the slice, and attach a slice property whose value is an X.509 cert containing the requesting guest's public key and the slice GUID. The guest controller should use this GUID as the GUID of the slice, rather than a GUID that it creates itself. The guest controller should pass the slice certification property through on all ticket and redeem requests for this slice. Brokers and authorities should check the certification when they first learn of a slice, and save it with the slice. [Note: this is not a required function, it simply provides compliance with the GENI CFA notion of a "slice authority".]

  • Within the Web portal, when an authorized user creates an actor,

mint a keypair for the actor, and create an X.509 certificate signed by the container and endorsing the public key of the new actor as bound to the principal of the requesting user. This enables the container to act as an identity provider. As a first cut, all users will issue their requests through Web portals that are bound to containers that are trusted as registered identity providers by the Clearinghouse (broker).