Security Profiles

Release 1.0 - ...

In order to protect your data, Smartsite has a completely new security model. It is a role based model that allows you to specify different credentials for each role in your system. These credentials are used to e.g. access your database or files on your disk. Every request that is made takes place using the credentials specified for that role such that a site administrator or editor can have e.g. read and write rights in your system while a site visitor can have only read access to your database and files.

We'll start with the security profile element in the Smartsite.Security.Config file which you can find in your site root. A security profile defines a set of credentials and specifies to which roles these credentials apply.

Here you can see an example of three defined security profiles, each being assigned to different roles. As you can see below, users in the Site Visitor role are using a readonly reference to the database whereas editors and the System Administrator also have write access. The asteriks (*) in the security profile Visitor means that any role that is not explicitly mapped to a security profile, is mapped to this role. Example of a Smartsite.Security.config securityprofiles section:

XML	Copy Code
<securityprofiles> <profile id="Visitor" userroles="VISITOR,*"> <database ref="MySiteReadOnly"/> <impersonate windowsaccount="Guest"/> </profile> <profile id="User" userroles="EDITOR"> <database ref="MySite"/> <impersonate windowsaccount="User"/> </profile> <profile id="System Administrator" userroles="ADMINISTRATOR"> <database ref="MySite"/> <impersonate windowsaccount="SystemUser"/> </profile> </securityprofiles>

XML

Copy Code

<securityprofiles>
 <profile id="Visitor" userroles="VISITOR,*">
  <database ref="MySiteReadOnly"/>
  <impersonate windowsaccount="Guest"/>
 </profile>
 <profile id="User" userroles="EDITOR">
  <database ref="MySite"/>
  <impersonate windowsaccount="User"/>
 </profile>
 <profile id="System Administrator" userroles="ADMINISTRATOR">
  <database ref="MySite"/>
  <impersonate windowsaccount="SystemUser"/>
 </profile>
</securityprofiles>

The database element references a database definition that can be found in the Smartsite.Data.config file. Note that a role may have access to more than one database. Multiple database references are comma separated and the reference to the Smartsite database must be the first reference. The database definition is pretty straight forward, except for the schema definition which we'll skip here. Example of the Smartsite.Data.config databases section:

XML	Copy Code
<databases> <database id="Falcon"> <connectionstring>Provider=SQLOLEDB.1;Password=12345;Persist Security Info=True;UserID=FalconAdmin;Initial Catalog=Falcon;Data Source=MyServer</connectionstring> <schema ref="Smartsite,MyObjects"/> </database> <database id="FalconReadOnly"> <connectionstring>Provider=SQLOLEDB.1;Password=55555;Persist Security Info=True;UserID=FalconReadOnlyAccount;Initial Catalog=Falcon;Data Source=MyServer</connectionstring> <schema ref="Smartsite,MyObjects"/> </database> <schemas> <schema id="Smartsite">... </schema> </schemas> </databases>

XML

Copy Code

<databases>
 <database id="Falcon">
  <connectionstring>Provider=SQLOLEDB.1;Password=12345;Persist Security Info=True;UserID=FalconAdmin;Initial Catalog=Falcon;Data Source=MyServer</connectionstring>
  <schema ref="Smartsite,MyObjects"/>
 </database>
 <database id="FalconReadOnly">
  <connectionstring>Provider=SQLOLEDB.1;Password=55555;Persist Security Info=True;UserID=FalconReadOnlyAccount;Initial Catalog=Falcon;Data Source=MyServer</connectionstring>
  <schema ref="Smartsite,MyObjects"/>
 </database>
 <schemas>
  <schema id="Smartsite">... </schema>
 </schemas>
</databases>

Having separate database connectionstrings for Site Administrators and Site Visitors allows you to prevent Site Visitors from having write access to your database and reduces the risk of security holes like sql injection leaks. As you probably noted in the security profile definition, security profiles may optionally have a impersonation element. When the impersonation is specified, the thread that executes the request is impersonated to that user at the start of the request. By using impersonation, you can use NT security to protect your files. You may e.g., create a secure folder that can not be browsed by Site Visitors by using NT security on that folder. The Windows account specified by the impersonation element can also be found in the Smartsite.Security.Config file. In this example, three Windows accounts are defined which can be referenced from a security profile.

XML	Copy Code
<windowsaccounts> <windowsaccount id="Guest" password="12345" username="FalconTestGuest" domain="mycompany" /> <windowsaccount id="User" password="12345" username="FalconTestUser" domain="mycompany" /> <windowsaccount id="SystemUser" password="12345" username="FalconTestAdmin" domain="mycompany" /> </windowsaccounts>

XML

Copy Code

<windowsaccounts>
 <windowsaccount id="Guest" password="12345" username="FalconTestGuest" domain="mycompany" />
 <windowsaccount id="User" password="12345" username="FalconTestUser" domain="mycompany" />
 <windowsaccount id="SystemUser" password="12345" username="FalconTestAdmin" domain="mycompany" />
</windowsaccounts>

Install & Config