Modelop Authentication

generated: '2026-08-25'
method: searched
source: >-
  https://modelopdocs.atlassian.net/wiki/spaces/MDHV/pages/3159996285/ModelOp+Center+Security+-+Oauth2+Integration
  + .../3159996249/Security+-+SAML+2.0+IdP+Integration
  + .../3159996790/Supported+OAuth+2.0+Identity+Providers
  + .../3159996694/Gateway+Authorization+mechanisms
  + .../3159996726/MLC+Authorization+mechanisms
  + .../3159996543/Granular+RWX+Details
  + .../3159992085/Permissions+Administration
checked: '2026-08-25'
derivation_note: >-
  DERIVED FROM DOCUMENTATION, NOT FROM A SPEC. ModelOp Center is customer-deployed software; its
  OpenAPI/Swagger document is served only from a customer's own instance
  (<base>/swagger-ui/webjars/swagger-ui/index.html?urls.primaryName=model-manage), so
  derive-authentication.py has no openapi/ file to read. Every field below is taken from the
  public documentation hub.
summary: >-
  ModelOp Center authenticates against the enterprise's own identity provider using OAuth 2.0 with
  OIDC, and authorizes with a group-based read/write/execute (RWX) model backed by AD/LDAP groups.
  There are no ModelOp-issued API keys and no ModelOp-hosted authorization server — the
  authorization server is whichever OAuth2 provider the customer already runs.
schemes:
  - id: oauth2-oidc-bearer
    type: oauth2
    primary: true
    description: >-
      OAuth 2.0 + OpenID Connect. Applies uniformly across the ModelOp Center web UI, the `moc`
      CLI, the REST APIs and the Jupyter / RStudio plugins.
    token_formats:
      - JWT
    flows_documented:
      - name: C2B (client-to-business)
        note: Interactive end-user login through the enterprise IdP; documented with a PingFederate walkthrough.
      - name: B2B (business-to-business)
        note: Service-to-service token flow between ModelOp Center components and external systems.
    authorization_server: customer-operated
    supported_authorization_servers:
      - PingFederate
      - Amazon Cognito
      - Okta
      - Microsoft Entra ID (formerly Azure Active Directory)
      - Keycloak
    note: >-
      ModelOp explicitly does not bind to one OAuth2 authorization server or IdP implementation;
      the docs hub carries a per-provider how-to page for each of the five above.
  - id: saml2-idp
    type: saml
    primary: false
    description: >-
      SAML 2.0 identity providers are supported indirectly — OAuth2/OIDC fronting a SAML2 IdP —
      via a separately installed `saml-support-service`.
    docs: https://modelopdocs.atlassian.net/wiki/spaces/MDHV/pages/3159996249/Security+-+SAML+2.0+IdP+Integration
  - id: basic-camunda-webapp
    type: http
    scheme: basic
    primary: false
    deprecated_in: '3.3'
    description: >-
      The embedded Camunda WebApp used basic login. From ModelOp Center 3.3, when secured mode
      with OAuth2/OIDC is enabled, that basic login is replaced by a security filter that admits
      only ADMIN-group users, and the WebApp is reachable only through the Gateway.
api_keys:
  issued: false
  note: No ModelOp-issued API key, client secret or personal access token scheme is documented.
authorization:
  model: rwx-group-access-control
  description: >-
    Read / Write / Execute permissions assigned to enterprise groups per entity, enforced at the
    lowest levels of every internal ModelOp Center call. Two user categories: Administrators
    (see all resources, manage Application Forms, Scores Configuration and permissions) and
    non-administrators (limited to the business units / groups they belong to).
  group_source: Active Directory / LDAP, surfaced through the OAuth2 OIDC provider
  multi_tenancy: true
  enable_flag: |
    modelop:
      security:
        mode: rwx
  configuration_example: |
    modelop:
      security:
        group-access-rights:
          default-permissions: read, write, execute
          collection-permissions:
            stored-model:
              - read
              - write
            deployable-model: read, write
  named_collections:
    - stored-model      # "Business Models and Monitors"
    - deployable-model  # "Snapshots"
  service_level_authorization:
    - service: gateway
      docs: https://modelopdocs.atlassian.net/wiki/spaces/MDHV/pages/3159996694/Gateway+Authorization+mechanisms
    - service: mlc-service
      docs: https://modelopdocs.atlassian.net/wiki/spaces/MDHV/pages/3159996726/MLC+Authorization+mechanisms
      protected_actions:
        - action: deploy (BPMN deployment)
          config_key: mlc.camunda.access.rest.deploy.groups
        - action: signal
          config_key: mlc.camunda.access.rest.signal.groups
        - action: signal-responsive
          config_key: mlc.camunda.access.rest.signal-responsive.groups
      note: >-
        Each action is gated on a comma-separated list of group names; admins always pass.
oauth_scopes:
  published: false
  note: >-
    ModelOp Center does not publish an OAuth SCOPE catalogue. Authorization is expressed as RWX
    permissions on entity collections held by IdP groups, not as OAuth scope strings, so no
    scopes/ artifact is emitted and no OAuthScopes pointer is wired. This is the same call made
    for key-auth providers in this pipeline: authentication/ carries the whole model.
data_handling_claim:
  claim: >-
    "ModelOp Center does not store any Customer business data sets; rather, ModelOp Center simply
    stores references to these data sets to leverage existing SecOps policies for these business
    data sets."
  source: https://modelopdocs.atlassian.net/wiki/spaces/MDHV/pages/3159996285/ModelOp+Center+Security+-+Oauth2+Integration