Security Improvements in 4.8
Last modified 08 Feb 2024 16:58 +01:00
Since 4.8
This functionality is available since version 4.8.
Table of Contents

Authorization Configuration

Before 4.8, we could specify the authorization only at the level of an object. For example, the logged-in principal could see particular items of a given object, depending on its relation to it. Or, it could execute some operations on that object.

In 4.8, we need more. First of all, we need to be able to authorize operations on the level of individual items.

  1. A user can see or complete case work items assigned to him.

  2. A user can see or complete case work items assigned to people in organizations managed by him.

  3. A user can see only closed (or not closed) case work items.

  4. A user can only see other users' assignments to the roles he is an owner or approver of.

  5. A user can only see other users' roleMembershipRef values related to the roles he is an owner of approver of.

Regarding certifications, things get even more complex:

  1. A user can see certification cases related to people in organizations managed by him.

  2. A user can see certification cases related to roles he is an owner or approver of.

  3. A user can see or complete certification case work items assigned to him.

  4. A user can see or complete certification case work items assigned to people in organizations managed by him.

  5. A user can see only closed (or not closed) certification case work items.

We cannot guarantee all of the above scenarios to be implemented. We will provide more detailed analysis here later.

Changes

  • The assignee clause now covers all assignees, not only assignees of open work items (commit c97e31dc).

Migration of the Authorizations

Please see Deprecated and Removed Authorizations more details.

Open Questions

Value-Level Action Authorizations

Currently, only the following authorizations are evaluated at sub-object level:

  1. #read (i.e., #search and #get)

  2. #completeWorkItem

  3. #delegateWorkItem

In particular, #add, #modify nor #delete ones are ignored at this level. Is it OK? Or, should we implement that? What will need to be resolved in that case, are relations to #assign and #unassign authorizations that would get an alternative representation of #add and #delete of AssignmentType value in assignment item.

The question is also whether we should apply sub-object authorizations when getEditObjectDefinition is called.

Answer (28th June 2023)

We may look at this, but with a lower priority.

Embedding of Value-Level Authorization Selectors

Currently, the following inner value types are automatically attached to their parents:

  • AssignmentType → AssignmentHolderType:`assignment`

  • CaseWorkItemType → CaseType:`workItem`

  • AccessCertificationCaseType → AccessCertificationCampaignType:`case`

  • AccessCertificationWorkItemType → AccessCertificationCaseType:`workItem` → AccessCertificationCampaignType:`case/workItem`

I.e. if there is an authorization with a selector with type = AccessCertificationCaseType, it is automatically interpreted as if it had parent selector of type = AccessCertificationCampaignType and path = case.

(See Specification#getCandidateAdjustments and Specification.Adjustment or their updates in current source code.)

Should we add another such auto-embedded cases? Is the treatment of AssignmentType ok? (Or, should we add inducement embedding for it?) Should we analyze the original container query and derive the attachments from there?

Answer (28th June 2023)

We will not support such an automatic embedding. Each sub-object selector must be rooted in a prism object. (TODO implement this)

Level of Support for searchContainers and searchReferences Methods

The searchContainers and countContainers currently support the following types regarding security:

  • AccessCertificationCaseType

  • AccessCertificationWorkItemType

  • CaseWorkItemType

  • OperationExecutionType

  • AssignmentType

  • SimulationResultProcessedObjectType

Among them, AssignmentType and SimulationResultProcessedObjectType are excluded from post-processing (i.e. application of #get authorizations on values returned by the search) because the repository does not return their parent objects.

Is that OK? E.g., should we add support for AssignmentType filtering? What about searchReferences? In particular, do we plan to filter the metadata (accesses) content according to authorizations in 4.8? If so, how?

Answer (28th June 2023)

We will have a look at both AssignmentType post-processing (i.e. returning the parent from the repository) and the implementation for searchReference - if the time permits.

Diagnostics Improvements

Are we going to somehow improve authorization diagnostics? The improvements in 4.8 tried to separate authorization and value selector evaluation logic from the diagnostic logging, in order to provide more flexibility in this area.

Should we provide alternative troubleshooting means in addition to existing one (i.e. by logging) ? For example, dumping the structured output into CSV? Or, integrating with the tracing?

Answer (27th June 2023)

The Authorization Playground page was created. It will be improved as the time permits.

Support for Specific Authorization Situations

The current authorization framework is quite general and flexible, but with many limitations restricting its practical use. What specific authorization scenarios should we support?

Answer (27th June 2023)

Engineers should create improvement issues what scenarios they need to handle.

Expression Profiles, Task Templates

Results of a design meeting (Katka, Rado, Pavol) on 11th of July 2023.

Main Use Cases

  1. Allowing delegation of auto-assignment selectors/expressions to non-root users.

  2. Allowing delegation of certain role management actions (involving editing of mappings) to non-root users. Especially for business roles.

  3. Allowing GUI customizations using expressions - e.g. in custom columns, but also using other expressions.

  4. Of course, continuing the support for expression in reports editable by non-root users.

  5. Custom GUI actions for object lists (that use task templates) should be callable by non-privileged users, even if they utilize Groovy code - MID-6913/MID-7831.

The Solution

  1. Selected expressions (mostly those mentioned in the use cases above) will run under defined expression profiles. These profiles will be derived typically from the archetype of the containing object (e.g., role).

  2. User will have the authorization to edit (parts of) objects with given archetype. They will NOT have the authorization to edit other expressions.

What about Task Templates?

Building blocks of the solution:

  1. Individual methods in function libraries could run under runAsRef/runPrivileged regime. (Maybe they even can do now, as they are basically expressions.)

  2. Function libraries will be callable from bulk actions (maybe even expressions as such could be).

  3. Bulk actions will execute under expression profiles as well.

  4. Function libraries will be covered by expression profiles i.e. one will be able to specify which libraries/methods are callable under given profile.

  5. Task template will provide a specific archetype that will be used to derive an expression profile for tasks derived from it. (These tasks will inherit the archetype on their creation.)

Determining Expression Profiles

  1. Primarily based on hosting object’s archetype plus item path[1]. (At first, we use the structural archetype, because the composition of expression profiles is tricky. [2])

  2. We may consider defining common profile for all GUI-related expressions, as they may reside on multitude of objects, e.g. even in user’s GUI config. Such configuration would be probably part of the system configuration object.

RunAsRef vs RunPrivileged

We create new configuration item, replacing runAsRef. It can be called e.g. privileges, and will cover the following:

  • runAsRef - if we want to switch the principal (actor) identity

  • runPrivileged - if we want to switch only the authorizations - by default to full ones ("setuid bit"); later we may be able to define specific authorizations to be used

If this is used in a custom library, it should be 100% hack-proof. (Although, we may be able to restrict availability of such a method via expression profiles.)

See Privilege Elevation (runAsRef, runPrivileged).

Other Considerations

Authorization Roles with Conditions

These conditions may require authorizations, but these are not available at login. The new runPrivileged feature will resolve this.

Auditing

  1. We certainly want to audit both original principal and the current actor (after one or more runAsRef directives).

  2. We also want to note when the privileges were messed with by the runPrivileged feature. Later, when runPrivileged allows adding specific (not all) privileges, we may consider recording details about privilege enhancements.

GUI Tasks Authorization Requirements

Should we require any authorizations in order to invoke tasks from GUI? (Like for assignment/unassignment of role members?)

Currently, we require (rather weak) #executeScript (now bulk-3#all) authorization to run bulk actions. In 4.8, we will continue requiring this; so the role owners will have to possess that authorization.

TODO ok?

Unrelated/Unsorted Notes (not part of the meeting)

Partial questions:

  1. What about unusual places where expressions can be found? E.g.

    1. expressions in explicit filters e.g. in search evaluators

    2. expressions in (implicit) dynamic reference filters (import-time filters do not support expressions)

    3. expressions in prism values e.g. configuration properties

    4. any other places?

Filter/query expressions:

Class Method Note

ContainerableListPanel

createReportPerformed

TODO

Search

evaluateCollectionFilter

TODO

PropertySearchItemWrapper

evaluatePredefinedFilter

TODO

ObjectCollectionSearchItemWrapper

createFilter

TODO

PersonOfInterestPanel

createAutocompleteFilter

TODO

CollectionProcessor

determineCollectionStats

Works on filter / domainFilter in CompiledObjectCollectionView; this is a compiled view from various collection objects, probably.

DashboardServiceImpl

countAuditEvents

The filter is created using some magic, see combineAuditFilter method in that class.

ModelInteractionServiceImpl

parseFilterFromCollection

Again, evaluating filters on CompiledObjectCollectionView.

TargetsEvaluation

createFilterEvaluator

Resolving dynamic targetRef filters in assignments or inducements during assignments evaluation.

ConstructionResourceResolver

resolveResourceRefFilter

Resolving dynamic resourceRef filters in constructions

ConstraintReferenceMatcher

filterMatches

Resolving dynamic filters in policy constraints: ExclusionConstraintEvaluator, HasAssignmentConstraintEvaluator.

ScriptingTaskCreator

createTaskFilterEvaluator

Looking for task templates for "execute script" policy action execution.

UnassignExecutor

resolveFilter

Filtering for assignments to be unassigned via bulk action.

ProvisioningContext

getProtectedAccountPatterns

Resolving protected accounts patterns.

SelectorToFilterTranslator

createFilter

Resolving filters in object selectors; currently used for linked objects (link source resolution).

AuthorizationEvaluation

createFilterEvaluator

Resolving filters in authorizations.

BasePrimaryChangeAspect

resolveReferenceFromFilter

Resolves approver references from various sources (policy rules, system configuration, etc).

PageRepositoryQuery

updateRequestWithMidpointQuery

Query playground in GUI

AbstractSearchExpressionEvaluator

createQuery

Queries in search-based evaluators (they have their expression profile determined anyway).

FilterCorrelator

evaluateQueryExpressions

Traditional filter correlator (expression comes from resource but sometimes from system configuration).

SearchEvaluator

evaluate

The search action in traditional (non-iterative) bulk actions.

AdvancedActivityRunSupportImpl

evaluateQueryExpressions

Resolving expressions in search-based activities (many of them).

ResourceObjectReferenceResolver

resolve

Resolving base context in provisioning.

Other places:

Component Use

GUI

  1. operation result scripting hook

  2. expressions for allowed values

  3. configurable expressions columns / containerable name column

  4. filter expression in PropertySearchItemWrapper

  5. flexible label model

  6. user display name from expression

  7. ExpressionValidator

Cases

  1. Delegator reference resolution

  2. Comment formatting (also in certifications)

Certifications

  1. cases generation (item selection expression)

  2. reviewers reference resolution

  3. delegators reference resolution

Expressions support

Custom functions evaluation (two places): see FunctionExpressionEvaluator (from XML) and CustomFunctions (from code)

Value policy processor

both generating and validating values

Dashboard service

dashboard variation (condition)

Object merger

value expression

Correlation

  1. confidence expression,

  2. expression-based correlator,

  3. confirmation expression,

  4. metric to confidence expression

Clockwork (privileged profile)

  1. audit property/recording expressions,

  2. clockwork hooks,

  3. provisioning operation context (for auditing)

Lens (various)

  1. policy rule condition,

  2. conditions in various policy constraints,

  3. localizable messages templates,

  4. iteration condition and token value,

  5. provisioning scripts,

  6. indexing (normalized properties),

  7. lifecycle transition conditions,

  8. scripting task creator,

  9. bulk action (initial) variables,

  10. simulation metrics computation,

  11. simulation metric domain/selection predicate matching,

  12. synchronization reaction condition,

  13. synchronization sorter evaluation,

Notifications

  1. event filtering condition,

  2. cc, bcc, body, subject, general recipient address, from, content-type expressions, generalized recipient, message attachments,

  3. custom notifier expression,

  4. custom message transport expressions,

  5. validating to/cc/bcc addresses,

  6. various expressions in SMS transport,

  7. lot of expressions in legacy transports,

Provisioning

  1. configuration properties,

  2. delineation conditions,

  3. shadow tag generation,

UCF

  1. Asynchronous provisioning: some transformation of outbound messages,

  2. Asynchronous update: processing of inbound messages

Reports

  1. generic scripts in reports,

  2. post-reports scripts

  3. TODO (inbound reports?)

Workflows

  1. auto-completion expressions,

  2. approver expressions,

  3. applicability condition (legacy change processor config)

Interesting cases:

  1. Expressions coming from various sources

    1. correlators (resource, system configuration)

    2. compiled collections/views

    3. policy rules

    4. approval schema fragments

    5. ?

How to Authorize Management of Template-Based Objects

There are objects that could be derived from templates (or super-objects): resources, archetypes, later maybe others. Do we need to specify authorization statements like:

  1. You can create/modify only resources derived from given template?

  2. You can/cannot create/modify resources derived from given template?

1. E.g. resource configuration properties vs. expressions in mappings
2. Consider resources of archetype/profile 1 ("strong", editable by power users) and archetype/profile 2 ("weak", editable by less trusted, wider group of people). If a resource have both archetypes 1 and 2, and if the profiles would be combined such as "the most powerful wins", then the wider group of people would be able to write scripts that would execute with strong privileges, which is bad.
Was this page helpful?
YES NO
Thanks for your feedback