links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Magma Security
Last updated at 4:52 pm UTC on 16 March 2010
3/16/2010: This is a historical page, out of date, and with incorrect information about today's state of Magma.

3/6/2006: I have finished the reviewing the security Magma 1.1, some adjustments are needed. 1.1 is still available as MagmaTesterLoader-cmm.14 should you wish to explore it although, regrettably, it is not secure.

Magma's security functions are factored into their own package known as KryptOn. It is believed these functions are useful to non-Magma programs.

Note: There is a hack to disable security, bottom of this page.

By design, the goal of KryptOn is to keep security information (capabilities) needed for accessing sensitive application elements separate from the application elements themselves, and to never expose such secure information anywhere outside a running image.

By way of KryptOn, Magma provides security in the following ways:
These services are on by default, but may be explicitly turned off.

Every repository is a MakoNode

With KryptOn, interactions occurring between two separate parties (nodes) occur in a "secure channel". This is a mathematical channel enabled by way of the public-key cryptography algorithms utilized by KryptOn. This secure channel is established by exchanging, in person or via a trusted third-party, MakoNodes, one representing each party.

Each party may have many MakoNodes representing themself, typically one for each other party they have established a secure-channel.

Every Magma repository is represented by its own MakoNode which is created automatically and added to your keyring file when creating the repository (you must #saveKeyring, however). Therefore Magma will request your keyring to create a repository (see KryptOn if you don't have a keyring but would like to generate one).

If you don't have a keyring, you must create one to use Magma:

For more information, see KryptOn.

Technical note: When creating a repository, actually two nodes are created. An additional node is created for the system session that it may submit its needed "housekeeping" requests as "just another client".

After creating the repository you must save your keyring, which now includes the additional MakoNodeKits.
	create: path
	root: rootObject.
  MakoSecurityManager saveKeyring 

Unless you use the #beMute: feature, described below, if you forget to save the keyring, the repository you created will be unopenable after saving your image.

Network Encryption

A MakoSession is negotiated automatically when connecting your MagmaSession (which may now happen implicitly). All network communications are then encrypted using whatever KryptOn-supported symmetric cipher algorithm was selected for this repository (Rijndael is the default).

Network encryption exacts a noticable performance penalty, if you don't need it, turn it off to go faster:
  myMagmaServerConsole cryptOnNetwork: false

File Encryption

All byte buffers are encrypted by the server before written to the objects file. Only the repository owner has the cipherKey needed to encrypt and decrypt these buffers. At best, an attacker who has heisted the repository files could, with great difficulty, gain visibility to the shape of the object graph. However all byte information (customer names, addresses, phone #'s) is encrypted and unreadable. Even the class names are encrypted so the heisted repository files could not even be opened for service, let alone any successful client connections established.

File encryption may be disabled any time:
  myConsole cryptInFiles: false

Existing buffers will remain encrypted until recommitted. Also, this is not a persistent choice, it must be done every time the repository is opened.

Request-level Authorization and Delegation

Every kind of MagmaRequest requires authorization. Only those who possess the required MakoCapability for a request can make the request. MakoCapabilities cannot be forged.

Delegation of authority can occur according to need without compromising security. For example, someone whom you've granted "Read" and "Write" access may, of their own volition, grant someone else Read without also having to grant them Write.

Granting Access

Generically, KryptOn allows grantage of any single capability to any single person by:
    exportFrom: myRepositoryController node
    to: granteeNode

While you can grant individual capabilities in this way, typically you need several capabilities to do anything with Magma. For example, to even make a connection you must have MaRepositoryConnectRequest and MaReadRequest. Therefore, Magma provides the following convenience methods for granting typical levels of access.

For read access:
  myRepositoryController exportReadCapabiltiiesTo: granteeNode

For read and write access:
  myRepositoryController exportReadWriteCapabiltiiesTo: granteeNode

For read and write and remote-admin access:
  myRepositoryController exportReadWriteAdminCapabilitiesTo: granteeNode

The capability files are exported to the directory specified by "MakoSecurityManager current exportDirectory". Give these files to someone in person or place it in a signedAndSealed envelope (a MakoEnvelope) addressed specifically to them and e-mail it to them; only they will be able to open it.

Granting access to the "public"

For convenience, after starting the Magma server, certain requests may be granted to the "public". This "public" access function is not directly supported by KryptOn, the Magma server simply caches the publicly-granted capabilities in its memory and considers every incoming request to have them.

Here are the public-granting messages:
  myRepositoryController grantReadToPublic
  myRepositoryController grantReadWriteToPublic
  myRepositoryController grantReadWriteAdminToPublic

  1. revokeFromPublic allows specific request types to be revoked.

Authorization applications

This authorization model satisfies several security use cases.


KryptOn uses "MakoCapabilities" to authorize access to a resource. Any possessor of the MakoCapability may "delegate" (export and give) it to someone else. Once granted, however, only the owner of the original capability (the original grantor) may revoke it at any time. The revocation affects everyone, even trusted parties, but this may be the best anyway..

Muting Security

The default behavior is, "maximum security". Network and file-encryption may be turned off. Authorization may effectively be turned off with #grantAllToPublic.

However, the client must still provide or generate a keyring because the handshake with the server is always required. The quick way to dispose of any further intrusions:
  MakoSecurityManager current beMute: true

This is a hack to mute the security intrusions when you absolutely do not want security. The next request for a keyring will generate and save one to the defaultSecurityDirectory. This is a global image setting, but it will not permit access to existing repositories with respect to their security settings (because it is enforced from the server side); but creating new repositories will be like old versions of Magma without security. Note that their secureness severely reduced.

But also note, if you do need security but wish to handle KryptOn user requests differently, note that your program may reply to the #defaultAction of these various Notifications as it wishes.

For example, the keyring file is encrypted with a password. KryptOn signals a MakoPasswordRequest, its #defaultAction uses a FillInTheBlank to get the users password. You may override this to get the password in your own way:
  [ MakoSecurityManager saveKeyring ]
	on: MakoPasswordRequest
		[ : request |
		request resume: self getThePasswordMyWay ]