Securing CruiseControl.Net – Web Dashboard (Part I: The Plan)
Posted by Craig Sutherland on 24 September, 2008
An Introduction
Previously I’ve written a series of posts on adding security to CruiseControl.Net. In these posts I talked about what I had done to secure the server and CCTray. This included authentication (identifying the user) and authorisation (what the user can do). However I had left the web dashboard untouched as I didn’t understand it.
Since then I’ve done some investigation on how the dashboard works and what I could do to add some security (and posted on the learning). Now it’s time to combine the two!
Rather than just jumping in and doing it, this post is about my plan on how I’m going to do it (actually it’s more about my ideas on how to do it, but very similar).
Returning To CCTray
At the end of my first security posts I had security working with CCTray – as long as .Net remoting was used. While the server was locked down, it was not possible to pass authentication and authorisation details through via the dashboard. My first step will be to remedy this failing!
The actions for handling XML requests are a custom set of XML-based actions. These are always added to the ObjectStore (i.e. they are hard-coded in CruiseObjectSourceInitializer). Some new security XML-based actions will need to be added. Once these actions are in place I can then modify HttpCruiseServerManager and HttpCruiseProjectManager in CCTrayLib to make use of them.
Currently I’m planning on adding a single security action that will handle login/logoff. I’m also going to modify XmlServerReportAction to handle sessions, and then track down which action or actions handle force and aborting builds and stopping and starting projects. Since the .Net remoting changes are already in place, this should be a simple matter of just passing through the parameters and returning the responses.
Adding Authentication to the Dashboard
Authentication is a bit harder. First off, there are potentially mutliple authentication methods. Secondly the dashboard can monitor multiple different servers – which may have different authentication methods and will have their own sessions.
To keep things simply I’m initially only planning on modifying the dashboard so the security is for a single server, but I hope to do this in an extensible way. I’m going to add a login/logout button to the header – next to the documentation link. To decide which version to display I’m going to added a decorator to the plugins that will check for a session token.
Session tokens will be the hard part, but I’m going to build a framework for these. It will be a plug-in that is defined in dashboard.config. It will need to hook into the URL generator (hence why I covered it) and also the new decorator I’m adding. The idea is the decorator will be called as part of the request chain, this will call the session plugin to retrieve the actual session id and set it so it can be used downstream. Any URLs that are generated can then use this session token.
Finally, the login view will also need to be extensible (to handle the different authorisation options). Initially this will need to be set in the configuration, so the users will be forced to use an authentication method. However in the long term I’m aiming to make this more flexible so the users can choose which authentication method to use (like CCTray). So this will be another type of plugin, but with the ability to interact with the session plugin.
Authorising Actions
With authentication locked down, authorisation is fairly simple. This is a matter of modifying some actions to pass the session id onto the server. Initially I’ll need to modify the actions that handle forcing and aborting builds, plus stopping and starting a project.
Since the session tokens are already parsed and set, all I should need to do is retrieve the token and pass it onto the .Net remoting calls.
Wrapping Up
When I’ve finished all this I’ll be just about done (and ready for some testing). But to help make things easier I’m planning on writing at least one post on using the new security settings. If there is anything you’d like me to cover, please let me know and I’ll add it in.
Anyway, enough planning, let’s start implementing
RSS - Posts