Introduction

ModelOp Center integrates with Oauth2 to enable enterprise-grade authentication and access control, including isolation of models by authorized groups and users, as well as role-based access control.

Table of Contents

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, 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 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, they 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, 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

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):

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. Therefore, they only have access to models and assets that are 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 access control. This approach does not tie ModelOp Center to a specific OAuth2 authorization server implementation.

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

Authorization Server:

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

PingFederate
KeyCloack

Supported Access Tokens:

The current architecture design supports different token formats, including:

JWT
Opaque

The current architecture design supports different token validations, including:

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

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 )

Token URI
Authentication URI
Issuer URI
Introspection URI
User Info URI (for opaque tokens)
SSO supported?
Token lifespan.

Access Token Details

Access token format.
Access token validation mechanism:
1. JOSE (JavaScript Object & Encryption)
  1. JWK details.
2. Opaque:
  1. Introspection URI.
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 comma separated string of values)
  1. Admin group - default modelop

Oauth2 clients required

Proposed Client id	Grant_types	client_secret (temp dev)	Scope	Redirect URL
gateway-service	Authorization_code Resource_Owner_Password_Credentials Access_Token_Validation (Client is a Resource Server) Refresh Token	CLIENT_SECRET_PWD	openid,profile,email	http://{RESOURCE_LOCATION}/login/oauth2/code/gateway-service
model-manage	Client_credentials Resource_Owner_Password_Credentials Access_Token_Validation (Client is a Resource Server) Refresh Token	CLIENT_SECRET_PWD	openid,profile,email
go-cli	Refresh_token Resource Owner Password Credentials	CLIENT_SECRET_PWD	openid,profile,email
mlc-service	Client_credentials	CLIENT_SECRET_PWD	openid,profile,email
reporting-service	Client_credentials	CLIENT_SECRET_PWD	openid,profile,email

Installation/Configuration

The following diagram shows the architectural diagram to enable an integration with PingFederate:

Moc-builder deployment pre-requisites with PingFederate:

For PingFederate using moc-builder, set the following values within the oauth/pingfederate section of the config.json file as shown here:

"oauth": {
        "pingfederate": {
            "gateway_client_id": "gateway-service",
            "gateway_client_secret": "CLIENT_SECRET_PWD",
            "mm_client_id": "model-manage",
            "mm_client_secret": "CLIENT_SECRET_PWD",
            "cli_client_id": "go-cli",
            "clie_client_secret": "CLIENT_SECRET_PWD",
            "rs_client_id": "reporting-service",
            "rs_client_secret": "CLIENT_SECRET_PWD",
            "mlc_client_id": "mlc-service",
            "mlc_client_secret": "CLIENT_SECRET_PWD",
            "auth_issuer_uri": "https://pingfederate:9031",
            "auth_token_uri": "https://pingfederate:9031/as/token.oauth2",
            "auth_user_info_uri": "https://pingfederate:9031/idp/userinfo.openid",
            "auth_jwk_set_uri": "https://pingfederate:9031/pf/JWKS",
            "auth_introspection_uri": "https://pingfederate:9031/as/introspect.oauth2",
            "auth_authorization_uri": "https://localhost:9031/as/authorization.oauth2"
        }
    },

Next, include the --oauth pingfederate flag in moc-builder compose to connect ModelOp Center with a running PingFederate instance.

Steps:

Start kubernetes from docker for mac
./moc-builder.py compose <your-desired-flags-here> --oauth pingfederate -l <your-label-here>
./moc-builder.py deploy --label <your-label-here>

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). For example, 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, Jupyter and RStudio plugins.

Here are some example configurations and restrictions of user access:

Group Base Access - descriptive table example:

User	Groups associated with user	Group A - Assets (StoredModels, DeployedModels, Runtime-Engines, etc…)	Group B - Assets (StoredModels, DeployedModels, Runtime-Engines, etc…)	Group C - Assets (StoredModels, DeployedModels, Runtime-Engines, etc…)	Admin - Assets (StoredModels, DeployedModels, Runtime-Engines, etc…)

User	Groups associated with user	Group A - Assets (StoredModels, DeployedModels, Runtime-Engines, etc…)	Group B - Assets (StoredModels, DeployedModels, Runtime-Engines, etc…)	Group C - Assets (StoredModels, DeployedModels, Runtime-Engines, etc…)	Admin - Assets (StoredModels, DeployedModels, Runtime-Engines, etc…)
Jane, Doe	GroupA
John, Doe	GroupB Group C
Admin One	GroupA,GroupC,Admin
Admin Two	Admin

API Enforcement of Group Based Access

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

StoredModels
DeployableModels
DeployedModels
ModelTestResutls
ModelBatchJobs
EngineNotifications
ModelNotifications
ModelTestNotifications
ModelReviewNotifications
Jobs

OAuth2 Integration: CLI, UI & API

Shown below are the detailed interactions that occur to enforce the authentication and group-based access control, in concert with the enterprise’s Oauth2 and AD/LDAP.

Within the CLI