Code Access Security (SCAS)

Smartsite iXperion uses declarative SXML Code Access Security (SCAS) for instruction elements.

Any SXML code that is executed is tested against the current Security Zone declared in the source field the instruction resides in. This way, execution of specific SXML elements can be limited in a very granular way.

For instance, you can prohibit the use of anything but normal translations in the 'body' field of normal web pages. Also, you can differentiate between normal- and system-translations and allow execution of specific SXML elements only if defined in System Translations. This is the out-of-the-box behavior since System Translations can be seen as 'building blocks' of RenderTemplates. 

Using the role based management features of the Cms, you can then disallow editing fields in specific roles.

Four separate SCAS aspects can be differentiated:

1. Zone declaration
2. ContentTypeField settings
3. SCAS mappings
4. Runtime security checks

Zone Declaration

Security Zones are declared in the smartsite.config file. A Security Zone defines an area in which specific SXML elements can be executed.

XML	Copy Code
<zones default="<default zone>">      <add name="<zone name>" description="<your descriptive string>"/>      [...] </zones>

By default, four zones are declared:

1. NoRisk
   Used for fields without any SXML, such as title, description, etc...
2. LowRisk
   Most body fields, except 'application'-like ContentTypes.
3. MediumRisk
   Application page body and normal translations. Inherits from LowRisk.
4. HighRisk
   Rendertemplate body and system translations. Inherits from MediumRisk.

Zones can be stand-alone, or can inherit from another zone. Zone inheritance allows for efficient and transparent configuration, but there might be scenario's in which it isn't desired.

These four zones are declared by default, but everyting here is optional: add your own zones at wish, or remove zones altogether, as long as you know what you're doing.

ContentTypeField settings 

The SecurityZone CTFP of any ContentTypeField is used to specify the zone on a per field basis. If no SecurityZone CTFP is set, the default zone as declared in the configuration file.

SCAS Levels

Vipers and macros can have the SXMLSecurityRiskLevel attribute set. This value can be 0,1 or 2. SCAS Level is nothing more than a default security classification which can be used to simplify the mapping of macros and vipers to security zones.

• SCAS Level 0
  ...
• SCAS Level 1
  ...
• SCAS Level 2
  ...

SCAS Mappings

Here, SXML instructions are mapped to one or more zones.

XML	Copy Code
<add matchtype="<match type>" expression="<expression>" zones="<zone_1[,zone_2][,zone_x]>"/>

There are several 'matchtypes' (types of mappings), based on the "XML Security asset type":

• ScasLevel
  The SXMLSecurityRiskLevel attribute set on the macro or viper at source code level (see documentation).
  This allows to quickly map them to security zones based on implied risk, using matchtype="scaslevel".
  
• Translation
  Translations with the TRA code or derived from it.
  
• SystemTranslation
  Translations with the TRT code or derived from it.
  
• Viper
  Viper methods other than translations, loaded from components.
  
• Macro
  All macros
  
• Any
  Catch all

Mappings can also specify an expression value. The value specified in expression depends on the type: For ScasLevel, it can be 0 (low risk),1 (medium risk) or 2 (high risk). For other types, it can be a string or a regular expression. If the expression starts with '/', it will be interpreted as a regular expression. Otherwise, the expression is tested against the beginning of the asset name. For instance,  the following declaration will assign the buffer.get viper method to the LowRisk zone (and to Medium- and HighRisk if inheritance is used):

XML	Copy Code
<add matchtype="viper" expression="buffer.get" zones="LowRisk"/>

Runtime security checks

At startup-time, the SCAS configuration is read by the publication engine, and is compiled into asset metadata that allows for very efficient lookups during runtime. 

At SXML execution time, the publication engine hosts an SXML stack object that knows the current instruction source (which ContentTypeField of which Smartsite item) when an SXML instruction is to be executed. It then checks the metadata attached to the SXML asset and simply compares its SecurityZones to the SecurityZone the current instruction source is in.