Pentaho uses Spring security under the hood – Version 4.1.3 as of 8.0. You don’t really need to know much about this except it’s an industry standard (for java at least) security layer.
The great thing about that, is the flexibility it gives for users/tweakers of the Pentaho platform.
For the Pentaho developers (way back in the day) it also meant they didn’t have to re-invent the wheel, and also rather handily by following industry standard it’s better from a security standpoint – hence there’s been very FEW security vulnerabilities in the Pentaho platform.
Anyway – It’s very very common to see these things in virtually all environments
- LDAP / Active Directory
- Roles/Permissions available in a database.
Now, I’ve been at a few places where LDAP contains both the users (for authentication) and the roles (for authorisation). And in those where they didn’t have the latter, we often recommend that LDAP is the right place for that. In some places this was achieved by creating distribution groups in outlook (!)
However in a lot of environments it can be very hard / slow to get data in LDAP updated. hence it may be nicer to store the authorisation data elsewhere, such as in a database.
Lo and behold! I was perusing the docs the other day, and this is clearly and concisely documented as a LDAP hybrid security option, read all about it here:
In fact, if you have to do any security configuration, LDAP or not, be sure to get up to speed with these docs and the files involved – it’ll help you understand the basic concepts.
Dan
Codeks Blog 
Pingback: Pentaho Security – Full JDBC – Passwords with Salts | Codeks Blog