This project is read-only.

XcoAppSpace Security Mechanisms

By default (meaning if the XcoAppSpace is instantiated with no additional security options), the XcoAppSpace doesn't provide any security mechanisms. If you use the XcoAppSpace e.g. in a private network where only authenticated users have access and you know that only your own applications communicate with each other this will most likely be sufficient though. But of course as soon as your workers become publicly available (e.g. over a large network or even the internet), security in absolutely necessary. The appspace therefore provides a security service interface that allows authentication and authorization of users that want to access certain workers. For this interface the space provides an implementation which is the XcoBasicSecurityService. This service offers basic security features in form of a simple user/role management and possiblities to store and load users from an xml file.
This page shows how the XcoBasicSecurityService can be used.

The XcoBasicSecurityService

The XcoBasicSecurityService provides role-based security, meaning that certain roles can be assigned to a user, and it can be defined which roles are allowed to access which ports of a worker.

Defining a secure worker

So, here is how to make a worker secure: The following code shows a simple example for a worker that takes int and string messages.
When defining the contract, there is no difference to an "unsecure" worker:
class PSecureWorker : PortSet<int, string>
{ }
It gets interesting when we come to defining the worker implementation class: Here you can add information on which ports of the worker can be accessed by certain roles by using the XcoSecurityPermission attribute. The attribute can be used to either mark the whole worker (when adding the attribute to the class definition), or only a single Port (when adding the attribute to the according processor method). In the following example you can see three roles:
  • The role name "WorkerRole" allows a user to access all ports of the worker
  • The role name "IntPortRole" allows a user only to access the worker's int port
  • The role name "StrPortRole" allows a user only to access the worker's string port
[XcoSecurityPermission("WorkerRole")] //If defined here, the role gets access to the whole worker
class MySecureWorker : PSecureWorker
{
	[XcoExclusive]
	[XcoSecurityPermission("IntPortRole")] //If defined here, only access to the corresponding port of the worker is allowed
	public void ProcessInt(int msg)
	{
		Console.WriteLine("Int Msg received: " + msg);
	}

	[XcoConcurrent]
	[XcoSecurityPermission("StrPortRole")]
	public void ProcessString(string msg)
	{
		Console.WriteLine("Str Msg received: " + msg);
	}
}

Using the security service

Making the worker secure is not the only thing that needs to be done. The space instance where the worker will be running needs to be equipped with the XcoBasicSecurityService, and of course users and roles need to be defined. This can be done directly with methods provided by the security service:
XcoBasicSecurityService security = new XcoBasicSecurityService();
security.AddUser("test1", "123", "WorkerRole"); //defines that the user "test1" with password "123" is assigned to the role "WorkerRole"
security.AddUser("test2", "123", "IntPortRole");
Additionally the service provides the methods AddRolle, RemoveUser and RemoveRole for user/role management.
Also, two other important properties of the XcoBasicSecurityService should be explained:
  • Policy: This property defines which security policy is used by the security service:
    • Permissive: Anonymous users are allowed (can access all workers/ports that are not restricted to certain roles). This is the default value.
    • Restrictive: No anonymous users are allowed.
  • StorePath: This property defines where the users are stored (if they are stored in an xml file). If a store path is set before instantiation (or during configuration) of the XcoAppSpace instance, the users will automatically be loaded from there. You can also save users by using the SaveUsers() method.
All possibilities of configuring the security service during XcoAppSpace startup are listed here.

The next thing is to add the security service to the space, for example like this:
XcoAppSpace space = XcoAppSpace.Configure.UsingService<XcoTCPTransportService>().OnPort(9001).UsingService(security);
space.RunWorker<MySecureWorker, PSecureWorker>();
This is the only thing to do, from then on you can run workers like always. If you take a look at the above code examples, the user "test1" would now have complete access to the worker because he has the role "WorkerRole". The user "test2" would only be allowed to post messages of type int because he only has the role "IntPortRole".

Connecting to secure workers

Before you can connect to a secure worker you have to specify credential for the user that you want to use for connecting. You can do this by using the space's Credentials property before calling ConnectWorker(). The specified credentials will be used for any ConnectWorker() call that is made.
space2.Credentials = new NetworkCredential("test1", "123");
var worker = space2.ConnectWorker<PSecureWorker>("localhost:9001");
As you can see the space uses the standard .Net credentials classes NetworkCredential and ICredentials.
With the given example, the worker would now be fully accessible, because the user "test1" has been used which has the role "WorkerRole" that allows full access, as specified above.

But what happens if a users doesn't have the rights to access a worker? If access to a worker is completely prohibited to a certain user, or an unknown user or wrong password is specified, an XcoSecurityException is thrown when calling ConnectWorker(). If the user only has permission to access some ports of the worker, and tries to access a port that he is not allowed to, an XcoSecurityException will be posted to your exception port if you have a causality installed (see error handling).

Limitations

An important thing that should be mentioned is that the current security service provides basic authentication and authorization functionalities - nothing more, nothing less. This means e.g. that it provides no message encryption! We think that this is a matter of the transport service, so if you want message encryption you should think about which transport service to use (e.g. WCF provides basic message encryption).
It is clear that the XcoBasicSecurity service is not a complete security solution for all scenarios in which the appspace could be used. Perhaps you already have security functions and would want to integrate these into the appspace. You can do this by implementing the XcoAppSpace.Contracts.Security.IXcoSecurityService interface yourself. If you are missing something important that you think would help people concering security in the appspace, then please drop us a note! We know that the current security features are just a start, and would very much like to hear what you think.
If you want you could even implement your own security service. See here for more info on how to do that.

Last edited Jun 16, 2010 at 8:10 AM by thomass, version 7

Comments

No comments yet.