- How are data authorizations managed in 1.x?
- Authorization syntax
- Authorization examples
- Authorizing a user to access an application
- Authorize a user to access applications using a matching a pattern
- Authorize a single user to access all applications
- Authorize access for a group of users
- Authorize access for all users
- Authorize a user to access applications using a specific technology
- Authorize a user to access applications assigned to a specific tag/category
- Restriction examples
How are data authorizations managed in 1.x?
Authorizations and restrictions are defined in the following files:
WAR 1.x CATALINA_HOME\webapps\<dashboard>\WEB-INF\authorizations.xml CATALINA_HOME\webapps\<dashboard>\WEB-INF\license.xml
The use of one or other, or both files depends on your dashboard deployment situation. A green tick indicates the file you should use.
| Deployment scenario | authorizations.xml | license.xml | Notes |
|---|---|---|---|
| Engineering Dashboard standalone (unrestricted license) |  |  | - |
| Engineering Dashboard standalone (restricted license) | | | See Dashboard Service license key configuration for more information about RESTRICTED license keys. It is not possible to define authorizations based on groups, the allUsers scope, patterns, tags, categories etc. when using license.xml. |
| Health Dashboard standalone | | | - |
| Engineering/Health Dashboard combined (unrestricted license) | | | - |
| Engineering/Health Dashboard combined (restricted license) | | | If you are using a combined WAR file (containing both the Engineering and Health Dashboards) AND you are using a RESTRICTED license for the Engineering Dashboard, you must define authorizations in both authorizations.xml (for the Health Dashboard) and license.xml (for the Engineering Dashboard with a restricted license). The authorizations do not need to be identical in each file if the user/group requires different authorizations in each dashboard. See Dashboard Service license key configuration for more information about RESTRICTED license keys. It is not possible to define authorizations based on groups, the allUsers scope, patterns, tags, categories etc. when using license.xml. |
Authorization syntax
Each line of the file defines an authorization to access an application or a group of applications. These lines are cumulative, therefore several lines can be applied to one single user or group, in which case, this user or group will have access to the all specified applications. Restrictions can be defined for an existing authorization and are used to prevent access to certain data if necessary. The syntax in use in the authorizations.xml/license.xml file is as follows:
<root> <authorization user_attribute="..." content_attribute="..." [content_attribute="..."] /> <authorization user_attribute="..." content_attribute="..." [content_attribute="..."] > <restriction content_attribute="..." [content_attribute="..."] /> <restriction content_attribute="..." [content_attribute="..."] /> ... </authorization> </root>
User scope, defined by the following attributes:
| attributes | Can be used with <authorization> | Can be used with <restriction> |
|---|---|---|
| user | | |
| group | | |
allUsers="true" | | |
Content scope, defined by the following attributes:
| attributes | Can be used with <authorization> | Can be used with <restriction> | |
|---|---|---|---|
| application, adgDatabase | | | Must be defined together - adgDatabase functions for both Dashboard schemas and Measurement schemas. |
| applicationPattern, adgDatabasePattern | | | Must be defined together - adgDatabasePattern functions for both Dashboard schemas and Measurement schemas. |
allApplications="true" | | | Functions for both Dashboard schemas and Measurement schemas. Note however that if this is used in an <authorization> and a child <restriction> is defined, the <restriction will be ignored. |
technology | | | Functions for both Dashboard schemas and Measurement schemas. |
| tag, category | | | Must be defined together and only function for a Measurement schema, except when the combined WAR/ZIP file is used, they will also be valid in the Dashboard schema for applications that exist in both schemas. |
Authorization examples
Authorizing a user to access an application
You can define authorization to a single application by specifying its name AND the name of the Dashboard schema in which the snapshot results for the Application are stored. For example, this line grants the "guest" user access to the "Billing platforms" application stored in the "demo_central" schema:
<root> <authorization user="guest" application="Billing platforms" adgDatabase="demo_central"/> </root>
Note that:
- the application and adgDatabase attributes MUST always be applied together to distinguish Applications.
- the adgDatabase attribute is case sensitive. Therefore you must ensure that the name of the Dashboard schema exactly matches the name defined in the Dashboard schema.
Authorize a user to access applications using a matching a pattern
You can authorize a user to access certain Applications based on regular expression pattern matching. With the following definition, the user "guest" will be authorized to access ANY applications (using ".+") where the host Dashboard schema is equal to "demo_80_central" or "demo_81_central" or "demo_82_central" or "demo_83_central" (using "demo_8[0-3]_central"):
<root> <authorization user="guest" applicationPattern=".+" adgDatabasePattern="demo_8[0-3]_central"/> </root>
Note that:
- pattern matching can only be applied to Applications (applicationPattern) and CAST Dashboard Services (adgDatabasePattern) - the two MUST always be applied together to distinguish Applications.
- the adgDatabasePattern attribute is case sensitive. Therefore you must ensure that pattern of the Dashboard schemas matches the case used in the schema names defined in CAST Storage Service/PostgreSQL.
Authorize a single user to access all applications
A user can be authorized to consume all applications - note that authorizations are additive, therefore this authorization overrides all other authorizations:
<root> <authorization user="Bill" allApplications="true"/> </root>
Authorize access for a group of users
In each of the above use cases already discussed, we can specify a group name in place of a user name. If Standard LDAP/SAML mode is being used:
- the group name must be specified using the full Common Name (CN) of the group
- nested groups are supported: if user jdoe is member of groupA which is in turn a member of groupB which is used to define an authorization, then jdoe will be attributed the groupB authorizations
Some possible examples are given below:
<root> <!-- authorize a Default Authentication group to access all applications --> <authorization group="demo" allApplications="true"/> <!-- authorize a Default Authentication group to access a specific application --> <authorization group="demo" application="Billing platforms" adgDatabase="demo_801_central"/> <!-- authorize an LDAP group to access all applications --> <authorization group="group.name" allApplications="true"/> <!-- authorize an LDAP group to access a specific application --> <authorization group="group.name" application="Billing platforms" adgDatabase="demo_801_central"/> </root>
Authorize access for all users
It is possible to authorize access to a single Application or to all Applications for all users - users means all authenticated users. For example, the following statement will allow all users to access data from the "Financial" application located in the "demo_central" Dashboard schema:
<authorization allUsers="true" application="Financial" adgDatabase="demo_central"/>
For example, the following statement will allow all users to access results from all applications:
<authorization allUsers="true" allApplications="true "/>
Authorize a user to access applications using a specific technology
By default, CAST will automatically assign the Category "Technologies" and the technology "Tags" to your Applications without the need to configure anything. As such, you can authorize users to access only specific Technology types. With the following definition, the user "DBA" will be authorized to access applications using the "Microsoft T-SQL" technology:
<root> <authorization user="DBA" technology="Microsoft T-SQL"/> </root>
Authorize a user to access applications assigned to a specific tag/category
The scope of applications can be defined with a tag and category name (see Health Dashboard tag and category management). With the following definition, user "Jacques" will be authorized to access all applications with the tag "France" in the category "Country":
<root> <authorization user="Jacques" tag="France" category="Country"/> </root>
Restriction examples
Restrictions must be used in conjunction with an authorization - they allow you to restrict access to content for the users/groups defined in the parent authorization:
- A restriction is defined via the <restriction> element.
- The <restriction> element must be a child element of an <authorization> element. It cannot be used on its own.
- A restriction can only be applied to authorizations that have been defined for tags/categories and technologies
- A <restriction> element does not take a user or group as an attribute, instead the restriction is applied to the user/group specified in the parent <authorization> element.
The syntax allApplications="true" cannot be used as an attribute of the <restriction> or the parent <authorization> elements - in other words, if it is defined the restriction will be ignored.
- Multiple <restrictions> can be used in a single <authorization> element.
When you are using the combined Health and Engineering WAR/ZIP file, restrictions based only on Tags and Categories created solely for Measurement schemas (Tag and Categories are features that are not available for Dashboard schemas) WILL also be applied in the Engineering Dashboard for applications that exist in both schemas.
Example 1
In the following example:
- an authorization grants access for all users to applications with the tag "France" in the category "Country"
- a restriction then limits access for all users to applications that have the tag "HR" in the category "Business Unit", in addition to the tag "France" in the category "Country"
- Therefore given the following configuration, only App1 will be accessible for all users:
- App1 has the tag "France" in the category "Country" AND the tag "HR" in the category "Business Unit"
- App2 has the tag "France" in the category "Country" AND "RandD" in the category "Business Unit"
<root> <authorization allUsers="true" tag="France" category="Country"> <restriction tag="HR" category="Business Unit" /> </authorization> </root>
Example 2
In the following example:
- an authorization grants access for all users to applications with the technology "Microsoft T-SQL"
- a restriction then limits access for all users to applications that have the technology ".NET", in addition to the technology "Microsoft T-SQL"
- Therefore given the following configuration, only App1 will be accessible for all users:
- App1 has the technology "Microsoft T-SQL" AND the technology ".NET"
- App2 has the technology ".NET"
<root> <authorization allUsers="true" technology="Microsoft T-SQL"> <restriction technology=".NET" /> </authorization> </root>
Example 3
In the following example:
- an authorization grants access for the user MIX to applications with the tag "Customer Relationship Management" in the category "Business Unit"
- a restriction then limits access for the user MIX to:
- applications that have the tag "Customer Relationship Management" in the category "Business Unit" in addition to the tag "8" in the category "Age"
- applications that have the tag "Customer Relationship Management" in the category "Business Unit" in addition to the technology "C"
- Therefore given the following configuration, only App2 will be accessible for all users:
- App1 has the tag "Customer Relationship Management" in the category "Business Unit" AND the tag "8" in the category "Age" AND the technology "C++"
- App2 has the tag "Customer Relationship Management" in the category "Business Unit" AND the tag "8" in the category "Age" AND the technology "C"
<root> <authorization user="MIX" tag="Customer Relationship Management" category="Business Unit"> <restriction tag="8" category="Age" /> <restriction technology="C" /> </authorization> </root>
