Chapter 8. Dynamic security
This chapter is recommended for
| Business analysts | |
| Data architects | |
 |
Enterprise architects |
|
Application developers |
In chapter 6 you saw how Adventure Works was able to use roles and grants to restrict access to data based on a user’s role. Most small and medium businesses that use Mondrian for internal only purposes can usually get by with such standard features. But as the numbers of users, roles, cubes, and clients grow, managing a Mondrian installation can become an administrative challenge. In a previous example from chapter 6, you saw how Adventure Works wanted to limit the state sales manager to only see the data from their state. The solution was to create a separate role for each state and assign managers to those roles, a tedious and error-prone solution. Additionally, many companies want to be able to provide Mondrian data to their clients. It’s imperative that each client only sees their own data and not data from other clients.
This chapter will discuss the solutions to these challenges. Although there are many approaches to solving these problems, the examples provided in this chapter are specific to Pentaho because most enterprise users of Mondrian use it as part of Pentaho. The examples in this chapter involve Java code and are mainly aimed at the software developer, but it’s important for the enterprise architect to understand these concepts as well.