Security¶
Starting with CruiseControl.NET 1.5.0, it is possible to add security to a CruiseControl.NET instance.
This page provides an overview of security for CruiseControl.Net on the server side. It includes how security works and why it might be needed. This includes defining the different parts of security and how they interact.
What is security?¶
The goal of security is to protect the system from unauthorized (and potentially malicious) users while still allowing authorized users the freedom to do their tasks.
As such this includes a number of different areas. In general security can be broken down into the following areas:- Authorisation: ensuring the user only has access to what they are allowed to use.
- Authentication: validating that a user is who they say they are.
- Auditing: logging what a person does, including the results of any attempted actions that failed (e.g. due to insufficient authentication or authorization)
The first two items can be thought of as active or preventive security. They stop the user from doing things they shouldn't. The third area is more of a passive area, but it is critical for preventing future attacks and diagnosing what has happened.
While there are other areas of security, these are the three areas that have been implemented for CruiseControl.Net.
How does security work for CruiseControl.Net?¶
Security for CruiseControl.Net has been implemented for the three areas listed above. All of these security areas has been implemented at the server level (for both console and service modes).
The security framework is designed to be configured in ccnet.config - otherwise the system will be treated as an open system (e.g. no security).
Additionally the framework is extensible - should the current components be insufficient for the security needs they can be replaced with custom components.
Authentication¶
Authentication is defined at the server-level. The administrator needs to define one or more users for the system.
These users can be validated by user name, user name/password or against an active directory domain.
Authorisation¶
Authorisation is defined initially at the project-level. This is because each project can have a separate set of permissions.
However, permission sets can also be defined at the server-level, and the project merely references these permission sets. This allows a common set of permissions to be defined for the entire server, with the projects then opting in as desired.
Auditing¶
Auditing is also defined at the server-level. This is to enforce consistent auditing across the entire server.
Auditing consists of two parts: one or more writers and a reader.
Each writer is responsible for writing audit information to a log somewhere. It is possible to configure multiple writers to allow writing information to different places.
A reader is responsible for reading an existing audit log so the information can be used in other places within CruiseControl.NET (e.g. the dashboard, etc.) Unlike the writers, there can only be one reader - otherwise CruiseControl.NET would get confused. The audit log that the reader reads from is referred to as the primary audit log.
Default Settings¶
The default server security manager is Null Server Security - this turns off security at the server level.
The default project security is Inherited Project Security - this will inherit all security settings from the server level.
Extensions¶
Security has been designed with extendability in mind. It has a large number of extension points to (hopefully) all possible scenarios.
Extending security is converted in Security Extension Points