Jump to content
  • This documentation is an older version of JasperReports Server Security Guide. View the latest documentation.

    Creating a Domain Security File

    A Domain’s security file contains item and resource access grants that specify access based on certain aspects of a user, such as roles. Typically, access grants check a user’s roles and grant access to the columns and rows available to that role.

    A Domain’s security file has two types of access definitions:

    Row-level access determines which rows in the data source can be displayed to a specific user.
    Column-level access determines which columns in the data source can be displayed to a specific user.

    This section illustrates both kinds of access grant.

    note-icon-ns_28x28.png.7e29b5ea4996bd1cb5b173670620d2bf.png

    Note the comments in the XML examples in this section; for example: <!-- Comment -->. It’s good practice to comment the access grants you define, and to format your XML neatly. We recommend using an XML editor when creating security files. See Domain and Security Recommendations.

    Row-level Security

    This section gives an overview of row-level security and then shows how CZS uses row-level security to restrict access based on Cities and ProductDepartment.

    Understanding Row-level security

    Row-level access determines which rows in the data source can be displayed to a specific user.

    For example, consider a table that includes values for the cities where products are sold. You could define a resource access grant that finds users for which a city has been defined as a profile attribute and, for each such user, limits access to rows where the city value is the user’s specific city.

    For example, take Rita and Alexi. Both have the same role and the same access to the Sales Numbers analysis view, but CZS doesn’t want them to see the same data—Rita should see data about San Francisco, Sacramento, and Los Angeles; and Alexi should see data about Osaka and Sakai. Without profile attributes, this would be possible only if CZS’s access roles were defined along geographic lines.

    The following resource grant gives access to users whose Cities profile attribute is San Francisco. The principle expression determines which users the resource access grant applies to (those whose Cities profile attribute is San Francisco). The filter expression determines the rows to display (rows where the store_city field is San Francisco):

    note-icon-ns_28x28.png.cf507c6077cf342f9b833552fa17f0cb.png

    Each access grant ID must be unique within the scope of the security file.

    You can define several similar resource access grants for each resource defined in your Domain. By default, the server assumes access grants are combined with a logical AND. You can force the server to use a logical OR by setting the orMultipleExpressions property to TRUE.

    The testProfileAttribute Function

    The expression in the previous section is limited. You don't want to write a separate expression for each instance of the Cities profile attribute — for example, one expression for San Francisco and another expression for Osaka. To avoid this, use the DomEl function testProfileAttribute.

    The testProfileAttribute function takes two parameters:

    testProfileAttribute(table_ID.field_name, 'profileAttribute')

    where:

    table_ID.field_name is the table name and field name of the field whose value you’re comparing to a profile attribute.
    profileAttribute is the name of the user profile attribute.

    For example, CZS used the following XML to define a principal expression and filter expression that grant access to users based on their Citiesprofile attribute:

    The principle expression is simple; it checks the Cities attribute of the logged-in user. The filter expression checks the user’s Cities profile attribute as well, but it compares this value with the values in the Domain’s store_city field. The Domain then returns all the rows that match the user’s Cities profile attribute.

    CZS’s Resource Access Grants

    CZS uses the access grant above to determine data access based on a user’s Cities profile attribute. Because CZS defines all their profile attributes in the same manner, they can use a similar resource access grant to determine data access for users based on their ProductDepartment profile attribute.

    The resulting security file included these two resource access grants (see the complete file in Domain Security File):

    Column-level Security

    Column-level access determines which columns in the data source can be displayed to specific users.

    Understanding Column-level Security

    Consider a table that includes employee contact and salary information. You could define item group access grants that check the user’s role and grant access to the salary field only if the user has the Human Resources role. For example, the following code sample modifies access for the ROLE_SALESREP role, first by revoking the default access for that role and then granting access to sales information only. The principle expression determines which users the item group access grant applies to (users with the ROLE_SALES_REP role). The item access grants determine the specific access of the users. All role-specific access is revoked then access to the StoreSales and StoreCost item is granted:

    CZS’s Item Group Access Grants for Sales Data

    To ensure that sales representatives don’t have access to cost information, CZS adds item group access grants; the first grants full access to managers and the administrator:

    CZS then adds an item group access grant that grants limited access to sales representatives; the following XML grants access to the Store Sales and Sales Units fields while revoking access to the Store Cost field:

    Uploading the Security File

    CZS uploads the security file each time they add a new access grant. You can upload the security file when you add or edit a Domain.

    js-czs-security-upload.png.365fac3fd4b77d2794c370f215c9708e.png

    Uploaded Security File in the Domain Dialog


    User Feedback

    Recommended Comments

    There are no comments to display.



    Guest
    This is now closed for further comments

×
×
  • Create New...