@@ -815,7 +815,7 @@ The operative context is described in more detail in the section [4.8 Operationa
#### Identity management
An identity management system is assures the identity of each subject which can be privileged or non-privileged within the system deployment context.
An identity management system assures the identity of each subject which can be privileged or non-privileged within the system deployment context.
The identity management system maintains a list of trusted sources, one or more, that describes what subjects are valid.
An up-to-date source of identity is essential.
@@ -831,13 +831,15 @@ These requirements apply to the product, regardless of the product's use case an
-**[REQ-AUTH-2]:** Product shall limit a natural user's authorisation validity of a session via a configurable setting that shall be initially limited by factory default of one day.
Depending on the product design, the identity management referred in [REQ-AUTH-0] can be either part of the deliverable product, part of the deployment context as outside source or both, where redundancy is desirable or necessary.
Integration into 3rd party identity management systems is preferred due to the higher likelihood that a dedicated identity management system is more likely to properly update or invalidate subjects credentials when necessary.
Integration into 3rd party identity management systems is preferred due to the higher likelihood that a dedicated identity management system is part of existing processes, up-to-date and can invalidate subjects credentials when necessary.
If the same system is used to grant the subjects access roles, for example through group membership, due diligence is required to assure that it meets the target security requirements in the intended or likely implementations of the product.
The relevance, availability, and correctness of the identity management system or service is crucial for the product and therewith for the entire network security, as it is the basis for the entire sequence from identity, over authentication up to the final user authorization.
Therefore due diligence is required during integration development to assure that the supported structures meets the target security requirements in the intended or likely implementations of the product.
Role based authentication has been established to be a reasonable method to control a large pool of subjects by grouping them together for example to task based sub-groups that grants access to partial set of functions.
These groups can be for example _billing reader_ or _project admin_ to grant access to related operations in the product.
It is more rare, that a person who focuses on financials would need access grants related to _project admin_ group, but it is reasonable to assume, that _project admin_ would need to understand how much the performed actions costs while assessing if projects is within the budget.
For example, it is not feasible that a financial accountant needs access as the _project admin group_, but it is reasonable to assume, that _project admin_ would need to understand how much the performed actions costs while assessing if projects is within the budget.
How the grouping is implemented is outside of this document.
#### Attribute-Based Access Control
@@ -849,7 +851,7 @@ The attributes that formulate the identity portion of the grant are often matche
> **ABAC Example:**
> An identified workflow execution A in a trusted environment B can amend the OCI registry C, under a project D, with a new container if the workflow is launched under trusted environment B organisation E, repository F.
In the above example, how the trust between the policy holder and the source environment is established can vary and there are different implementations in the market.
In the above example, the trust relationship between policy holder and the source environment can be established in various ways with different implementations.
Attribute-Based Access Control design and implementation is outside of the scope of this standard.
