Identity, principals, and authorization

Security concepts model identities, principals, permissions, and authorization expectations before they are mapped to AWS IAM or Cognito.

Source: mde/metamodels/pim/pim-security.emf.

`IdentityProvider`

Represents identity provider in the PIM vocabulary. It specializes TraceableElement, DeployableElement, PolicyTarget, ProtectedResource with the details needed for this modeling concern.

Direct supertypes: TraceableElement, DeployableElement, PolicyTarget, ProtectedResource. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`federationRequired`	`Boolean` [1]	Records whether federation required applies to identity provider. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `FederatedIdentityShouldDescribeTokenAndAttributes` (federated identity should describe token and attributes) in `mde/validation/pim/rules/security-config-external.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `IdentityProvider2CognitoUserPool` in `mde/transformations/pim-to-awspsm/workflow-security-config.etl` reads or derives this feature while refining `IdentityProvider`.	Either `true` or `false`. Example: `true`.
`mfaRequired`	`Boolean` [1]	Records whether mfa required applies to identity provider. The field records an explicit architectural or governance decision as an explicit, reviewable input. Transformation role: ETL rule `IdentityProvider2CognitoUserPool` in `mde/transformations/pim-to-awspsm/workflow-security-config.etl` reads or derives this feature while refining `IdentityProvider`.	Either `true` or `false`. Example: `true`.
`issuer`	`String` [1]	For a identity provider, the model records whether issuer applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Identity Provider Issuer`.
`audience`	`String` [*]	Records the audience value for the identity provider. This keeps the decision explicit even when the element's class or relationships remain unchanged. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`.	A collection of values. Example: [`Identity Provider Audience`, `Identity Provider Audience-2`].
`tokenType`	`String` [1]	For a identity provider, the model records the controlled classification or strategy represented by token type. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `FederatedIdentityShouldDescribeTokenAndAttributes` (federated identity should describe token and attributes) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `BUSINESS`.
`tokenValidationRules`	`String` [1]	For a identity provider, the model records the token validation rules value. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `IdentityProvider2CognitoUserPool` in `mde/transformations/pim-to-awspsm/workflow-security-config.etl` reads or derives this feature while refining `IdentityProvider`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`jwksUri`	`String` [1]	For a identity provider, the model records the URI/URL from which jwks is obtained. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `https://example.com/orders`.
`userAttributeRequirements`	`String` [1]	For a identity provider, the model records the user attribute requirements value. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `FederatedIdentityShouldDescribeTokenAndAttributes` (federated identity should describe token and attributes) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Identity Provider User Attribute Requirements`.
`passwordPolicyDescription`	`String` [1]	For a identity provider, the model records the human explanation of password policy description. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `STANDARD`.
`identityKind`	`IdentityKind` [1]	Records controlled classification or strategy represented by identity kind for identity provider. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	Exactly one of: `USER_DIRECTORY`, `FEDERATED_IDENTITY`, `MACHINE_CLIENT`, `API_KEY_CLIENT`, `SERVICE_PRINCIPAL`, `EXTERNAL_IDENTITY_PROVIDER`. Example: `USER_DIRECTORY`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`principals` → `Principal`	reference, [*]	References the principal element(s) used as principals by this identity provider; the target may be shared elsewhere in the model.

`Principal`

Represents principal in the PIM vocabulary. It specializes TraceableElement, PolicyTarget, ProtectedResource with the details needed for this modeling concern.

Direct supertypes: TraceableElement, PolicyTarget, ProtectedResource. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`principalKind`	`PrincipalKind` [1]	Stores the accountable person, team, or identity for principal kind on the principal. The field records accountability and access review as an explicit, reviewable input. Transformation role: ETL rule `Actor2Principal` in `mde/transformations/cim-to-pim/boundaries-security.etl` assigns or materializes this feature while refining `Principal`. ETL rule `Role2Principal` in `mde/transformations/cim-to-pim/boundaries-security.etl` assigns or materializes this feature while refining `Principal`.	Exactly one of: `HUMAN_USER`, `GROUP`, `ROLE`, `SERVICE`, `EXTERNAL_SYSTEM`, `ANONYMOUS`. Example: `HUMAN_USER`.
`externalRef`	`String` [1]	Stores the external ref value on the principal. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Transformation role: ETL rule `Actor2Principal` in `mde/transformations/cim-to-pim/boundaries-security.etl` assigns or materializes this feature while refining `Principal`. ETL rule `Role2Principal` in `mde/transformations/cim-to-pim/boundaries-security.etl` assigns or materializes this feature while refining `Principal`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Principal External Ref`.
`privileged`	`Boolean` [1]	Records whether privileged applies to principal. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `PrivilegedPrincipalNeedsPermissions` (privileged principal needs permissions) in `mde/validation/pim/rules/security-config-external.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Actor2Principal` in `mde/transformations/cim-to-pim/boundaries-security.etl` assigns or materializes this feature while refining `Principal`. ETL rule `Role2Principal` in `mde/transformations/cim-to-pim/boundaries-security.etl` assigns or materializes this feature while refining `Principal`.	Either `true` or `false`. Example: `false`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`permissions` → `Permission`	containment, [*]; opposite `principal`	Contains the permission element(s) that make up this principal; the contained objects belong to this model element.

`Permission`

Represents permission in the PIM vocabulary. It specializes TraceableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`providerActionOverride`	`String` [1]	Stores the provider action override value on the permission. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Permission Provider Action Override`.
`action`	`String` [1]	Records the action value for the permission. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `PermissionIsScoped` (permission is scoped) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank. `LeastPrivilegeShouldBeConfirmed` (least privilege should be confirmed) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/validation.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Permission Action`.
`resource`	`String` [1]	Records origin/source selected for resource for permission. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `PermissionIsScoped` (permission is scoped) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank. `LeastPrivilegeShouldBeConfirmed` (least privilege should be confirmed) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/contracts.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Permission Resource`.
`condition`	`String` [1]	For a permission, the model records the expression or rule that governs condition. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`conditionExpression`	`String` [1]	For a permission, the model records the expression or rule that governs condition expression. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`leastPrivilegeRationale`	`String` [1]	For a permission, the model records the reasoning behind least privilege rationale. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `The choice protects the business outcome while keeping the design independently deployable.`.
`leastPrivilegeConfirmed`	`Boolean` [1]	For a permission, the model records whether least privilege confirmed applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `LeastPrivilegeShouldBeConfirmed` (least privilege should be confirmed) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank.	Either `true` or `false`. Example: `false`.
`leastPrivilegeStatus`	`LeastPrivilegeStatus` [1]	Records controlled classification or strategy represented by least privilege status for permission. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	Exactly one of: `UNREVIEWED`, `GENERATED_BROAD`, `REVIEW_REQUIRED`, `CONFIRMED_LEAST_PRIVILEGE`. Example: `UNREVIEWED`.
`effect`	`PermissionEffect` [1]	Stores the controlled classification or strategy represented by effect on the permission. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/iam.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/values.eol`.	Exactly one of: `ALLOW`, `DENY`. Example: `ALLOW`.
`actionKind`	`PermissionActionKind` [1]	Records controlled classification or strategy represented by action kind for permission. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	Exactly one of: `INVOKE`, `READ`, `WRITE`, `DELETE`, `LIST`, `PUBLISH`, `SUBSCRIBE`, `CONSUME`, `ENCRYPT`, `DECRYPT`, `READ_SECRET`, `MANAGE`. Example: `INVOKE`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`principal` → `Principal`	reference; read-only, [1]; opposite `permissions`	References the principal element(s) used as principal by this permission; the target may be shared elsewhere in the model.
`targetResource` → `ProtectedResource`	reference, [1]	References the protected resource element(s) used as target resource by this permission; the target may be shared elsewhere in the model.

`SecurityPolicy`

Represents security policy in the PIM vocabulary. It specializes ArchitecturePolicy with the details needed for this modeling concern.

Direct supertypes: ArchitecturePolicy. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`authenticationRequired`	`Boolean` [1]	Records whether authentication required applies to security policy. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityPolicy`.	Either `true` or `false`. Example: `true`.
`authorizationRequired`	`Boolean` [1]	Records whether authorization required applies to security policy. The field records an explicit architectural or governance decision as an explicit, reviewable input. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityPolicy`.	Either `true` or `false`. Example: `true`.
`authStrength`	`String` [1]	Records the auth strength value for security policy. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityPolicy`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Security Policy Auth Strength`.
`encryptionInTransitRequired`	`Boolean` [1]	For a security policy, the model records whether encryption in transit required applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityPolicy`.	Either `true` or `false`. Example: `true`.
`encryptionAtRestRequired`	`Boolean` [1]	Records whether encryption at rest required applies to security policy. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityPolicy`.	Either `true` or `false`. Example: `true`.
`auditRequired`	`Boolean` [1]	For a security policy, the model records whether audit required applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityPolicy`.	Either `true` or `false`. Example: `true`.
`secretsRequired`	`Boolean` [1]	Records whether secrets required applies to security policy. The field records an explicit architectural or governance decision as an explicit, reviewable input. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityPolicy`.	Either `true` or `false`. Example: `true`.
`threatModelNotes`	`String` [1]	Stores the threat model notes value on the security policy. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityPolicy`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Security Policy Threat Model Notes`.

Relationships

This class declares no direct relationships.

`AuthPolicy`

Represents auth policy in the PIM vocabulary. It specializes SecurityPolicy with the details needed for this modeling concern.

Direct supertypes: SecurityPolicy. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`authScheme`	`String` [1]	Records the auth scheme value for auth policy. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `AuthPolicyHasScheme` (auth policy has scheme) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `AuthPolicy`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Auth Policy Auth Scheme`.
`mfaRequired`	`Boolean` [1]	Records whether mfa required applies to auth policy. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `AuthPolicy`.	Either `true` or `false`. Example: `true`.
`tokenValidationRules`	`String` [1]	Records the token validation rules value for auth policy. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`scopesRequired`	`String` [1]	For a auth policy, the model records the boundary within which scopes required is interpreted. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orders`.
`requiredClaimsExpression`	`String` [1]	For a auth policy, the model records the expression or rule that governs required claims expression. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`identityProvider` → `IdentityProvider`	reference, [?]	References the identity provider element(s) used as identity provider by this auth policy; the target may be shared elsewhere in the model.

`AuthorizationPolicy`

Represents authorization policy in the PIM vocabulary. It specializes SecurityPolicy with the details needed for this modeling concern.

Direct supertypes: SecurityPolicy. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`ruleExpression`	`String` [1]	Records expression or rule that governs rule expression for authorization policy. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `AuthorizationPolicyHasDecisionLogic` (authorization policy has decision logic) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank. `ResourceLevelAuthorizationShouldHaveExpression` (resource level authorization should have expression) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `AuthorizationPolicy`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`roleOrScopeRequired`	`String` [1]	Records the boundary within which role or scope required is interpreted for the authorization policy. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `AuthorizationPolicyHasDecisionLogic` (authorization policy has decision logic) in `mde/validation/pim/rules/security-config-external.evl` the value must be present and non-blank. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `AuthorizationPolicy`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `order-manager`.
`resourceLevelAuthorization`	`Boolean` [1]	Stores the origin/source selected for resource level authorization on the authorization policy. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `ResourceLevelAuthorizationShouldHaveExpression` (resource level authorization should have expression) in `mde/validation/pim/rules/security-config-external.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `AuthorizationPolicy`.	Either `true` or `false`. Example: `false`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`rule` → `Expression`	containment, [?]	Contains the expression element(s) that make up this authorization policy; the contained objects belong to this model element.
`allowedPrincipals` → `Principal`	reference, [*]	References the principal element(s) used as allowed principals by this authorization policy; the target may be shared elsewhere in the model.
`permissions` → `Permission`	reference, [*]	References the permission element(s) used as permissions by this authorization policy; the target may be shared elsewhere in the model.