Security

In our business, security is one of the major concerns. It has to be the cornerstone of the architecture , and it drives each layer and component within.

Principles

Concerns

RESTful API

As a fundamental business requirement, our core system exposes all of its functionality to the outside world. It has to be secure enough so we can even run our web front end at a different location, accessing the system using the exact same API everyone else.

As basic conditions we have that the API is only available via HTTPS , and that all public applications validate the ssl certificate of the server each time they connect to it.

...

Permissions

In order to enforce our four-eyes principle and to make the system scaleable, some services and persons need to view the actions and data. To guarantee that the information and actions are only available to parties authorised to see it, the business logic implements a very strict permissions/delegations system, and keeps a detailed log of the actions.

...

Applications

Applications are the keystone . They securely allow people to do things in our system using the API . Applications are considered to have their own credentials, permissions and responsible members.

for Applications acting on behalf.

The web front end application acts on behalf of our user but without having access to her credentials. The application has to get a delegation from the user to perform certain tasks in her name.

For this purpose of API access delegation, OAuth is being considered. This is an an open standard started in 2007, and is currently pushed/endorsed by twitter, Google, Yahoo! and others.

for Applications only needing authentication.

Other applications in the CAcert Community need to authenticate the member only, and do not need full access to the user's data or actions. Examples: CATS; geo/social, an emerging app that aims to help members find assurers and to contact people for events. These applications need only limited access to our core data: to know her status (assured, Assurer), and maybe if a name or mail address is verified or not.

For authenticating users remotely OpenID is being considered. This is an open standard that has the ability to add status information. Checking the status of a member is something every other member has the right to do.

If a name or mail address is verified, we probably need a delegation.

There are concerns about traceability with OpenID, which may be addressed by making the system opt-in. But this simply pushes the burden to the Member, and is not particularly helpful to our principles. However, at this stage of development, this is a minor concern.

External resources

See also