Today’s technology innovations have made collaboration easier than ever before, but different groups throughout organizations need to have access to shared and restricted information in a secured and centralized way, relative to the context of their specific business needs. ModelOp Center, embracing current needs for teams to collaborate across different areas, supports multi tenancy access, making sure that just the right groups are able to access the right data or execute specific actions, fully supporting isolation of models--and all of their sensitive assets--by specifying personalized groups at existing centralized managed domain services, such as Active Directory’s or LDAP. This approach ensures that, for example, Team 1 cannot see Team 2’s sensitive models and associated assets. All of the requisite internal ModelOp Center calls are designed to enforce this group-based (RWX - Read, Write, Execute ) access control, at the lowest levels. ModelOp Center uses this approach to allow enterprises to leverage their existing processes and systems for user management (Oauth2 + AD/LDAP) to manage groups and which users have access to these groups. ModelOp Center integrates with these existing systems to enforce authentication and access control within ModelOp Center.

From an end-user perspective, ModelOp Center is designed to accommodate two distinct user categories or roles: Administrators and non-administrators. Administrators possess higher access privileges, enabling them to seamlessly navigate and interact with all resources available within ModelOp Center. In contrast, non-administrators are restricted to accessing resources that are exclusively associated with the specific business units or groups to which they belong. This segregation of access ensures that non-administrators can only engage with data and features that are relevant to their respective business units and responsibilities. This is carried across the ModelOp Center web interface, CLI, APIs, and Jupyter/RStudio plugins.

Additionally, 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.

End User Flow (C2B)

Please see below a few examples of how the “group-based” access control flow appears and is enforced for a few types of users:

User Login Example (using Ping Federate):

Open

Open

Admin User (superuser) Access

As a super admin user, all resources are visible and available for the user.

In the Dashboard, they are able to see a summary of all items, from top Models By Business KPI to Issues by Business Unit.

Within the Business Models Inventory, the admin is able to see the details of all models:

Within the Runtimes page, the admin is able to see the details of all runtimes (engines):

End User Access (e.g. Data Scientist or ModelOps Engineer in Group 1)

The ModelOps engineer or data scientist has been added to Group 1 within the enterprise’s Oauth2/LDAP structure. Hence, he/she only has access to models and associated assets assigned to Group 1.

In the Dashboard, therefore, they are only able to see a limited set of the resources available across the enterprise

In the Business Models Inventory, they are limited to viewing only the models that belong to their group which has 2 models.

In the Runtimes page, they are limited to viewing only their group’s runtimes, in this case current user has 2 runtimes associated to his group.

Technical Details

Architecture Overview

ModelOp Center architecture is designed to integrate with different implementations of OAuth2 service providers, leveraging best practices and taking advantage of multiple abstractions to enable enterprise-grade authentication and authorization. This approach does not tie ModelOp Center to a specific OAuth2 Identity Provider (IdP) server implementation.

The following diagram provides a high level overview of the OAuth2 components and responsibilities existing inside ModelOp Center:

Flows represented in the diagram:

• C2B (Client to Business) flow represented with gray tokens

• B2B (Business to Business) flow represented with green tokens

Authorization Server:

The current architecture design supports different implementations of OAuth2 Authorization Server, including:

• PingFederate

• Amazon Cognito

• Okta

• Azure AD

• Keycloak

Supported Access Tokens:

The current architecture design supports different token formats, including:

• JWT

• Opaque

The current architecture design supports different token validations, including:

• JWKs

• Opaque

• JOSE

Internal and External Component Communication:

All communications, internal or external, are managed by the gateway-service component, a reverse proxy acting as a protected resource and OAuth2 Client, performing authorization and delegating authentication to the OAuth2 Authorization Server.

Internal ModelOp Center components such as reporting-service, mlc-service , document-service and model-manage have been defined with the client_credential access grant, to be able to interact with each other through the gateway using valid and unexpired access tokens issued by the Oauth2 Authentication Server (the aforementioned components represent the B2B flow).

Microservices defined as oauth2-clients are required to include a predefined scope in tokens, so that can be correctly differentiated from EndUser requests (C2B flow).

Pre-requisites

In order to successfully integrate ModelOp Center with OAuth2, the following pre-requisites should be provided:

OAuth2 Authentication Server Details ( .well-known configurations )

1. Token URI

2. Authentication URI

3. Issuer URI

4. Introspection URI

5. User Info URI (for opaque tokens)

6. SSO supported?

7. Token lifespan.

Access Token Details

1. Access token format.

2. Access token validation mechanism:

   1. JOSE (JavaScript Object & Encryption)

      1. JWK details.

   2. Opaque:

      1. Introspection URI.

3. Access token fields

   1. Username or user_id

   2. given_name 

   3. family_name

   4. email

   5. member_off (access group claim that can be a list or a comma separated string of values)

      1. Admin group - default modelop

   6. OAuth2 clients:

      1. scope: modelop_client

Minimum Required OAuth2 Clients

Extended OAuth2 Clients

Group Base Access Control

Technical Use Case Scenarios

ModelOp Center leverages OAuth2 integration to fully support isolation of models and their sensitive assets by specified teams (groups). This ensures that Team 1 is unable to see Team 2’s sensitive models and associated assets. All of the requisite internal ModelOp Center calls are designed to enforce this group-based access control, down to the lowest level of the architecture. ModelOp Center uses this approach to allow enterprises to leverage their existing processes and systems for user management (OAuth2 + AD/LDAP) to manage groups and their membership. ModelOp Center integrates with these existing systems to enforce authentication and access control within ModelOp Center.

Users are only allowed to access and interact with the models, assets, and runtimes with which they are permitted. This is carried across the ModelOp Center web interface, CLI, API’s and certified plugins.

Here are some example configurations and restrictions of user access:

Group Base Access - descriptive table example:

Note: Specific configurations among OAuth2 IdPs may change.

API Enforcement of Group Based Access

ModelOp Center enforces the group-based access to all internal ModelOp Center API calls, including:

1. StoredModels

2. DeployableModels

3. DeployedModels

4. ModelTestResutls

5. ModelBatchJobs

6. EngineNotifications

7. ModelNotifications

8. ModelTestNotifications

9. ModelReviewNotifications

10. Jobs