Create your own Namespace
scone-cas.cf is a shared infrastructure. To isolate policies, CAS supports namespaces. Actually, namespaces can be nested. The creator of a namespace can control who can create policies in this namespace, who can read the namespace and who can update the namespace. In other words, the creator gets full control of this namespace. Nobody, no system admin, no admin of the CAS, can get access to this namespace - as long as the SCONE CAS runs in production mode.
For our experiments, we create a separate namespace at public CAS
scone-cas.cf and use this in the context of this tutorial. Note that
scone-cas.cf runs in debug mode, i.e., we need to accept this when attesting
scone-cas.cf should only be used for development and testing.
scone CLI creates a public/private key pair and only this key pair enables us to access this namespace. This key pair is stored in the home directory of the user. For now, we assume that the machine on which the user executes the CLI is trusted. In a later assignment, we will show how to protect this public/private key pair and the configuration information of the
The scone policy language will evolve over time. The version of the policy language should be specified as part of the policy. If we forget to specify the version, right now, an old version of the policy language is selected, i,e., version "0.2". As soon as version "0.2" is not supported anymore, not specifying a version will result in an error.
In this assignment, you should not specify a version. This will prevent us to actually generate nested policy (- since this was not yet supported in version "0.2"). We do this, to fix this mistake in the next assignments. We will learn how to update a policy or a namespace to a new version "0.3".
Create a script in your favorite scripting language that
- creates a new namespace
- ensures that only you can create sessions in this namespace
ensures that the name of your namespace is unique
checks if it already created a namespace
if it was already created, do not recreate but use the existing namespace
ensure that the script is idempotent
can be restarted in case it execution was interrupted previously or if it already ran previously
store the name of the namespace and the hash value of the policy
- to ensure that we can find the session later again, and
- that we can update the session
To ensure that we do not conflict with other users, we can generate a new namespace that starts with a prefix like "my_assignment-" and then append the user name and a random number:
You can print the name of the namespace as follows:
echo "The name of the namespace is $NS"
You can check if a namespace exists by reading the policy that describes the namespace:
scone session read "$NS"
If the namespace does not yet exists, you could create a minimal policy that might look like this:
name: $NS version: "0.2"
In a nutshell, this policy specifies a
name: in this case given by environment variable
version: in this case given "0.2" - which is actually a version that is already deprecated.
An implicit access policy is defined: only the
creator - identified by its public key - can read or update this policy. In other words, only an entity that knows the private key belonging to the public key can identify itself as the
A policy cannot be deleted. This is to avoid issues that policies can be deleted and later be replaced by a brand new policy. One can, however, update policies. We will
- change the version number, and
- add some explicit some access policy
in a later assignment.
Say, you store this policy in file
session.yml, you can then create this policy with the
scone session create CLI as follows:
scone session create -e NS="$NS" session.yml
Note that option
-e <VAR=VALUE> permits to add or overwrite existing variables in the given session file. We call a file that does contain environment variables like
$NS a session template. Only if all environment variables are replaced by values, CAS will this as a syntactically correct policy (a.k.a., a session).
In this example, one could also use flag
--use-env. In this case, the environment variables defined when call
scone session create are used for variable substitution. Note that option
-e has priority of the environment variables: if a variable
$NSis defined both in the environment as well as via
-e, the value defined by
-e is used.
Each policy has a hash value. This hash value is returned when creating or updating the session. This might look like this:
A solution for this task for
bash is available at assignment 2.
- Please have a look at the troubleshooting hints from the previous assignments. If you experience any additional issues, please let us know via email. We will add the issue and a proposed solution to this troubleshooting section.