Sonntag, Oktober 11, 2009

CCNet 1.5 Security

Letzte Woche habe ich bestimmt 3-4h rumgefummelt um Security von einem CCNet-Server zu konfigurieren. Die Beschreibungen in der Dokumentation finde ich noch nicht so aussagekräftig.

Um Security zu nutzen ist es erst mal erforderlich, die Security auf Server-Ebene zu aktivieren, dies geschieht durch das internalSecurity-Attribute direkt unter dem Root-Node “cruisecontrol”.

   1: <internalSecurity>
   2:   <cache type="inMemoryCache" duration="20" mode="sliding"/>
   3:   <users>
   4:     <ldapUser name="*" domain="YOURDOMAIN.local"/>
   5:   </users>
   6:   <!--<audit>
   7:     <xmlFileAudit location="c:\ccnet_audit.log"/>
   8:   </audit>-->
   9:   <permissions>
  10:     <rolePermission name="SpecialPermission" forceBuild="Allow" viewProject="Allow" viewConfiguration="Allow" defaultRight="Deny">
  11:       <users>
  12:         <userName name="Special.User1"/>
  13:       </users>
  14:     </rolePermission>
  15:     <rolePermission name="ServerAdministrators" defaultRight="Allow">
  16:       <users>
  17:         <userName name="Special.User2"/>
  18:       </users>
  19:     </rolePermission>
  20:     <rolePermission name="general" forceBuild="Deny">
  21:       <users>
  22:         <userName name="*"/>
  23:       </users>
  24:     </rolePermission>
  25:   </permissions>
  26: </internalSecurity>

Da ich nicht extra Benutzer und ggf. Passwörter definieren, verwalten und sichern möchte, muss unser Active Directory dafür herhalten. Hierfür gibt es bei ccnet das “ldapUser”-Element. In meinem Build von 08.10.2009 funktionierte es nicht richtig in unserer Domaine, ich habe dazu einen Bug entsprechend angelegt. Es scheint als muss der Ldap-Helper für komplettes durchsuchen des ADs konfiguriert werden. Zu dem ist vermutlich der Zugriff über den Global Catalog (GC) schneller.

Anschließend ist für den Server die Security aktiviert. Nun kann man mit der “defaultProjectSecurity” die Rechte für das aktuelle Projekt definieren. Da die Security für ein Projekt ist, muss dieses auch unterhalb eines “project”-Tags folgen. Man kann bei der Permission des Projects  auf die Permissions des Servers referenzieren. Ich habe direkt die Permission zu spezifizieren nicht ausprobiert, kann aber noch kommen.

   1: <security type="defaultProjectSecurity">
   2:   <permissions>
   3:     <rolePermission  name="Administrators" ref="ServerAdministrators"/>
   4:     <rolePermission  name="Testers" ref="SpecialPermission"/>
   5:   </permissions>
   6: </security>

Nach der Aktivierung der Security sieht man auf der Startseite von CCNet nichts mehr, sofern nicht jeder Berechtigt ist.

image

Erst durch Auswahl des Servers, zumeist auf der linken Seite, und anschließendem Login, bekommt man die Projekte zu sehen.

image

Schade ist, dass man sich separate anmelden muss um Zugang zu bekommen, allerdings ist das nachvollziehbar, da die Security nicht durch die Web-App geprüft und verwaltet wird, sondern durch den CC-Server, der über Remoting mit der Web-App redet. Vorteil ist allerdings, dass so viele verschiedene CCNet-Server durch eine WebApp verwaltet werden können und unterschiedliche Berechtigungskonfigurationen aufweisen können.

Größtes Hinderniss war der oben erwähnte Bug, mal schauen, ob die Änderung in das Release noch hereinkommt. Aber nun funktioniert es sauber und ich kann alle auf das Web-Interface loslassen, da jeder nur seinen Teil sieht. :)

Vielleicht kommt demnächst noch etwas zu Parametern, die ebenfalls neu in 1.5 sind und etwas Dynamic in der CCNet-Prozess bringen.

Zum Schluß noch ein kleiner Verweis auf einen ineressanten Blog-Post zum Thema “Bootstrap your build – good practice for CruiseControl.Net”. Projektbestandteile oder ganze Bereiche auszulagern, ist super interessant.

Keine Kommentare: