Unknown macro: {scrollbar}

Introduction

Looking for a quick start? Just work from the checklist.

Design Goals

The security system of the Pentaho BI Platform strives to meet the following requirements:

Unobtrusive: Security is a cross-cutting concern; it should be as unobtrusive as possible.
Extensible: The security system must provide the option to extend key classes to fit users' needs.
Flexible: The security system should be easily customized, preferably declaratively.
Portable: To the greatest extent possible, the security system should not use container-specific libraries.

Spring Security

In the Pentaho BI Platform, security is based on the infrastructure provided by Spring Security.

Note: Because the platform builds on top of Spring Security, it is highly recommended that readers consult the Spring Security documentation. The online documentation for Spring Security is for the latest version of Spring Security. The Pentaho BI Platform is based on Spring Security 2.0.5. There can be significant differences between the latest Spring Security version and the version used by the Pentaho BI Platform. For this reason, it is not recommended that you use the online documentation. Instead, go to the Spring Security downloads page and download the Spring Security archive which when expanded creates a docs/apidocs directory. Opening index.html with your browser then allows for local browsing of the correct version of Spring Security documentation.

How this Document is Organized

The remainder of this document covers the following security areas, after a brief terminology introduction.

Area	Description
Security data access objects	Security data includes usernames, passwords, granted authorities, web resource (URL) protection data, and ACLs for domain objects.
Authentication	This area is concerned with processing interactive login information (e.g. username and password) and comparing it with data retrieved from the security datastore.
Web resource (URL) authorization	Protecting URLs is a matter of answering for each user, whether or not they can access each URL (web page). Note that access here is `Yes` or `No`--there is no `Read` or `Write` granularity. Given an authenticated user, it is the responsibility of web resource authorization to decide whether to allow the page to be accessed.
Domain object authorization	Currently, the only domain objects protected by the platform are solution repository objects (e.g. action sequences). Given an authenticated user, it is the responsibility of domain object authorization to decide whether to allow the requested operation.