Security Scenario 2: Large Team
!!Update!!
Since this post security has been modified slightly. Please see this post for further details.
Welcome Back to Security
Here is the second in a set of scenarios on security. In my previous scenario (here) I looked at a small team, this time I’ll look at a large team.
The company Acme Banking, a large multi-national bank. Lu is the manager of the lending application software development department and has a staff of 19 people working for him. He has charged his system admin, Peter, with securing CruiseControl.Net.
Some background, Lu is responsible for three applications: lending applications system (LAS), load approval and tracking system (LATS) and bad debt analysis and recovery system (BARS). Each system is an independent web application with a complex set of business rules and a backing database. To allow interactions between the system each application exposes web services. Finally each application has a number of support tools that are Windows-based.
However, to simplify things, Lu’s department is only responsible for development. The QA department is responsible for all testing (including deployments) and the Server department is responsible for the actual deployment to PROD. All of these deployments are done via hand-overs, with the receiving department responsible for getting the binaries from the build server.
As for department structure, each team has a team leader and a senior developer. There are also between two and six junior developers in each team. Peter is not included in any of the teams as his full-time role is supporting the developers. All staff are on the same network and have windows logins.
Lu wants to limit access for project to the team that is responsible for it. No team is allowed access to any project that belongs to another team. Additionally only the team leader and senior developer are allowed to start/stop the projects, although the junior developers can force builds. Everything done in the system must be audited.
The Build Setup
Each application has two projects – main and tools. Main includes the actual web application, plus the web services, while tools contains all the support tools. This makes a total of six projects.
Each project contains everything required to build the binaries and deploy them to the build server (for the other departments). These are triggered on an interval basis, plus every night at 3am.
Since the hand-over process is manual, there is no impact on other environments. However considering the team size and low-level of trust they want everything locked down.
The Goals
There will be three security zones: low, medium and high. The following table shows these zones:
| Zone | Description | Projects | People |
| Low | Permission to force/abort builds. | All | Junior developers |
| Medium | As above, plus permission to start/stop projects | All | Team leaders and senior developers |
| High | As above, plus access to security information | None | Lu & Peter |
Each application will be divided into low and medium zones. The high level security zone is generic to the system rather than application-specific.
The Plan
These goals give a total of seven security groups – low and medium for each application plus a high security group. Everybody within the department will belong to one of these seven groups.
This actual model is a little more complex, but I’ve put together a diagram as follows:
The Configuration
Again I’m going to use the same basic configuration for each project:
<project name=”LAS-Main”>
<workingDirectory>C:\Build\LAS-Main</workingDirectory>
<artifactDirectory>C:\Build\LAS-Main\Deploy</artifactDirectory>
<webURL>http://localhost/server/local/project/LAS-Main/ViewProjectReport.aspx</webURL>
<triggers>
<intervalTrigger buildCondition=”IfModificationExists” seconds=”300″/>
</triggers>
<publishers>
<xmllogger/>
</publishers>
</project>
The project name (i.e. LAS-Main) will be changed for each project – a total of six projects.
Again the first step is turning on security – just added the sessionSecurity element, plus the settings and assertions children.
Adding The Roles and Users
Next, I added the users. Since everyone is on the network I added them with ldapUser elements. This is defined as follows:
<settings>
<ldapUser name=”lu.jones” domain=”localhost”/> <!– Manager –>
<ldapUser name=”peter.smith” domain=”localhost”/> <!– SysAdmin –>
<ldapUser name=”mark.doulos” domain=”localhost”/> <!– LAS Team leader –>
<ldapUser name=”jill.white” domain=”localhost”/> <!– LAS Senior developer –>
<ldapUser name=”john.asher” domain=”localhost”/> <!– LAS Junior developer –>
<!– Remaining users omitted –>
</settings>
Note there is a domain in here – I’ve just changed it to localhost for this example. Without the domain the active directory authentication will fail as the authenticator won’t know where to look.
I’ve also added a server-level assertion for the high-security permissions:
<assertions>
<roleAssertion name=”Admin” defaultRight=”Allow”>
<users>
<userName name=”lu.jones”/>
<userName name=”peter.smith”/>
</users>
</roleAssertion>
</assertions>
This just says that Lu and Peter have full access to everything.
Configuring the Clients
This is exactly the same for scenario one for CCTray. Each individual user will need to go in and configure their security authentication. The only difference is they can use the WinLogin authentication method.
At the moment it is not possible to add the authentication to the dashboard. I’ll look into adding a authentication plug-in and then I’ll update this post.
Locking Down Projects
The final step is to lock down the projects. This is where there is slightly more work than scenario one. Since each project needs to be secured, every project will need to be modified.
There are two ways this can be done. One way would be to add the security to each project, the second is to define roles and then link each project to them. Since there are two projects for each application, with identical permissions I’m going to use the second approach.
In the settings section of sessionSecurity I define each application role. The following shows an example:
<roleAssertion name=”LAS-Developers” forceBuild=”Allow” defaultRight=”Deny”>
<users>
<userName name=”john.asher”/>
<!– Remaining users omitted –>
</users>
</roleAssertion>
<roleAssertion name=”LAS-Admin” forceBuild=”Allow” startProject=”Allow” stopProject=”Allow” defaultRight=”Deny”>
<users>
<userName name=”mark.doulos”/>
<userName name=”jill.white”/>
</users>
</roleAssertion>
This defines the developer and admin (team leader/senior developer) roles for an application. Each of the other applications has a similar definition except with a different list of users.
Then, in each project I add a security section like the following:
<security type=”defaultProjectSecurity” defaultRight=”Deny”>
<assertions>
<roleAssertion name=”LAS-Developers” ref=”LAS-Developers”/>
<roleAssertion name=”LAS-Admin” ref=”LAS-Admin”/>
<roleAssertion name=”Admin” ref=”Admin”/>
</assertions>
</security>
The first two assertions will change to match the application each project is for, while the last one is the same for all projects (gives Peter & Lu access to the projects).
Audit Logging
Finally Lu wants everything audited. This is very simple to do, just add an audit logger and an audit reader. This is done in the sessionSecurity element by adding the following elements:
<audit>
<xmlFileAudit/>
</audit>
<auditReader type=”xmlFileAuditReader”/>
By default these will use an audit log called SecurityAudit.xml in the same directory as the executables. This can be changed by added a location attribute as follows:
<audit>
<xmlFileAudit location=”C:\Logs\CCNet_Audit.xml”/>
</audit>
<auditReader type=”xmlFileAuditReader” location=”C:\Logs\CCNet_Audit.xml”/>
Note that the location must be on both elements and they point to the same location. This is because the two items work independently of each other and it is possible to have multiple audit loggers.
And that’s the security settings for this scenario.
Some Comments
As always, working through this scenario I found a couple of issues.
First, while the LDAP security is generic (i.e. the authentication is handled externally) I still needed to define every user. This is because of the internal validation that happens. As different users would belong to different roles I couldn’t just use a wildcard for the authentication. While this does make things a little more security, it also forces duplication of security 
Instead it would be nice to define something that keys off an LDAP group, hence reducing the need for duplication.
Secondly there is no dashboard plug-in to detect a Windows Login. I haven’t implemented this as I’m not sure of the best way yet (if anybody has any suggestions let me know!) This wouldn’t be so bad, except the only way to view the audit logs currently is via the dashboard!
Complete Configuration
Once again I have posted the complete example on my storage site:
There is no dashboard configuration for the reason above.
Feel free to send me any suggestions for improvements or ideas on how to clarify these scenarios or security in general.
