...
The Grouper API is distributed with example configuration files with ".example" inserted in the middle of their names. These should be renamed or copied to remove the ".example" substring, or doing a build with ant will do this, or it is already copied in the binary distribution. e.g. for grouper.properties, the example file is grouper.example.properties.
Section | Configuration File | Purpose |
---|---|---|
grouper.hibernate.properties | integrating the Grouper API with the database that will house your Groups Registry | |
sources.xml | integrating the Grouper API with chosen identity sources | |
grouper.properties | defaults for Grouper privileges, enabling identified external users to act with elevated root-like privilege, changing the display name for internal subjects | |
log4j.properties | logging | |
grouper-loader.properties | auto-load memberships from external sql sources, register notification consumers, validate Grouper Rules, update enabled/disabled flags, etc |
Anchor | ||||
---|---|---|---|---|
|
Database-Related Settings and Procedures
...
Grouper uses Hibernate to persist objects in the Groups Registry. Database-specific settings are configured in conf/grouper.hibernate.properties, which has pre-populated examples for HSQLDB, MySQL, Oracle, and Postgresql.
Required properties are:
Property Name | Purpose |
---|---|
hibernate.connection.driver_class | JDBC driver classname |
hibernate.connection.url | JDBC URL for the database |
hibernate.connection.username | database user |
hibernate.connection.password | database user's password Note, you can also put a filename of the encrypted password |
hibernate.dialect | classname of a Hibernate dialect, for setting platform specific features. Choices are listed (Hibernate Reference Documentation - Chapter 3. Configuration - 3.3. JDBC connections - 3.4.1. SQL Dialects) here |
You may need to refer to your database support person to determine these required properties.
...
MySQL Syntax: ANALYZE TABLE table_name
http://dev.mysql.com/doc/refman/5.5/en/analyze-table.html
PostgreSQL Syntax: ANALYZE table_name
http://www.postgresql.org/docs/8.4/static/sql-analyze.html
Oracle Syntax: exec dbms_stats.gather_table_stats('schema', 'table_name', cascade => TRUE);
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm
Note, you can analyze a subset of the rows in oracle if you have a lot of data
Code Block |
---|
select 'ANALYZE TABLE ' || table_name || ' estimate STATISTICS sample 100000 rows;' as script from user_Tables where table_name like 'GROUPER%'
e.g. ANALYZE TABLE GROUPER_ATTRIBUTES estimate STATISTICS sample 100000 rows;
or, e.g. ANALYZE TABLE GROUPER_ATTRIBUTES compute STATISTICS; |
In all cases, substitute "table_name" with each table that you want to have analyzed. For Oracle, also substitue "schema" with the database schema for your Groups Registry.
MySQL example...
...
When a new group or naming stem is created, any of its associated privileges can be granted by default to the ALL subject. This is configured by a series of properties in grouper.properties, one per privilege. If a property has the value "true" then ALL is granted that privilege by default when a group or naming stem is created. Otherwise it is not, and hence no subject has that privilege by default. The groups read and view settings below are set to true to make the quickstart easier to run. If you have an deployment where privacy among Grouper users is important, you should consider changing those to false so that access to see or view memberships of groups must be explicitly assigned.
Property Name | Value in Grouper v1.5 Distribution |
---|---|
groups.create.grant.all.admin | false |
groups.create.grant.all.optin | false |
groups.create.grant.all.optout | false |
groups.create.grant.all.update | false |
groups.create.grant.all.read | true |
groups.create.grant.all.view | true |
stems.create.grant.all.create | false |
stems.create.grant.all.stem | false |
attributeDefs.create.grant.all.attrAdmin | false |
attributeDefs.create.grant.all.attrOptin | false |
attributeDefs.create.grant.all.attrOptout | false |
attributeDefs.create.grant.all.attrRead | false |
attributeDefs.create.grant.all.attrUpdate | false |
attributeDefs.create.grant.all.attrView | false |
Anchor | ||||
---|---|---|---|---|
|
...
Grouper has another special "subject" called GrouperSysAdmin that acts as a super-user. GrouperSysAdmin is permitted to do everything - the privilege system is ignored for that special subject. Grouper can be configured to consider all members of a distinguished group to be able to act as super-users, much as the "wheel" group does in BSD Unix. Two properties control this behavior:
Property Name | Description |
---|---|
groups.wheel.use | "true" or "false" to enable or disable this capability. |
groups.wheel.group | The group name of the group whose members are to be considered security-equivalent to GrouperSysAdmin. |
The Grouper UI enables users that belong to the wheel group to choose when to act with the privileges of GrouperSystem and when to act as their normal selves.
...
Before version 1.3.0 the Grouper UI referred to EveryEntity as GrouperAll and GrouperSysAdmin as GrouperSystem. As of version 1.3.1 the name attribute of GrouperAll and GrouperSystem can be set through the properties below.
Property Name | Description |
---|---|
subject.internal.grouperall.name | The name to use for GrouperAll instead of EveryEntity |
subject.internal.groupersystem.name | The name to use for GrouperSystem instead of GrouperSysAdmin |
If you choose not to use the defaults you will have to update the UI nav.properties file to ensure consistency e.g. subject.privileges.from-grouperall=inherits from EveryEntity
...
Grouper's internal security implementation relies on two java interfaces, one for Naming Privileges and another for Access Privileges. Grouper ships with classes that implement these interfaces, but 3rd parties are free to supply their own and so manage Grouper privileges using a privilege management system external to Grouper. Two properties declare the java classes that Grouper will use to implement these interfaces:
Property Name | Description |
---|---|
privileges.access.interface | classname of the java class that implements the Access Interface |
privileges.naming.interface | classname of the java class that implements the Naming Interface |
privileges.attributeDef.interface | classname of the java class that implements the Attribute access Interface |
It is not clear that this has been taken advantage of... the internal privilege management is the one usually used. Also, performance of the system will be drastically reduced if external privileges are used, since internal privilege management can join tables in one query to securely select from the registry. If you want to store privileges externally, another option is provisioning the internal access adapter settings and table data from an outside system.
...
To enable the change log, set this:
Property Name | Default Value | Description |
---|---|---|
changeLog.enabled | true | if we should insert records into grouper_change_log_temp when events happen |
If you are using ldappc, then you need to keep updating the last membership time. If not (and not using this column for other custom reasons), you will reduce the number of queries by setting this to false.
Property Name | Default Value | Description |
---|---|---|
groups.updateLastMembershipTime | true | If true, when a membership is added to a group (either a privilege or a list member), |
stems.updateLastMembershipTime | true | If true, when a membership is added to a stem (this would be a naming privilege), |
Anchor | ||||
---|---|---|---|---|
|
Logging
...