Image Added

In the Models page, they are limited to viewing only the models that belong to their group, which is simply 1 model for now:

Image Added

In the Runtimes page, they are limited to viewing only their Group’s runtimes, which is simply the “engine-aml” runtime:

Image Added

Architecture Overview

ModelOp Center architecture was designed to integrate with different implementations of Oauth2 service providers, following best practices and taking advantage of multiple abstractions to enable enterprise-grade authentication and access control, without being tied to a specific Oauth2 authorization server implementation.

This diagram provides a high level overview of the Oauth2 components and responsibilities exiting inside ModelOp Center:

Authorization Server:

The current architecture design supports different implementations of Oauth2 Authorization servers such as:

• PingFederate.

• UAA - Cloudfoundry.

Supported Access Tokens:

Token format supported:

• JWT.

• String.

Token validation supported:

• Opaque

• JOSE

Internal and external component communication:

All communications (Internal/External) are managed by the Gateway-service component, a reverse proxy acting as 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 AccessTokens issued by the Oauth2 Authentication Server.

Pre-requisites

In order to successfully integrate ModelOp Center with Oauth2, enabling enterprise-grade authentication and access control, the following pre-requisites should be provided:

Oauth2 Authentication Server details

1. Get Token URI.

2. Authentication URI.

3. Issuer URI.

Access Token Details

1. Access token format defined.

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

   1. Last_name

   1. Email

   1. Access group list.

Oauth2 clients required

Installation/Configuration

The next diagram shows the architectural diagram to enable an integration with PingFederate.

Moc-builder deployment pre-requisites with PingFederate:

For Pingfederate through moc-builder, make sure the fields sent , contain their correct values in the oauth/pingfederate section of the config.json file, it’ll look like this:

"oauth": {
        "pingfederate": {
            "gateway_client_id": "gateway-service",
            "gateway_client_secret": "abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPOnmlijhoauthplaygroundapplication",
            "mm_client_id": "model-manage",
            "mm_client_secret": "abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPOnmlijhoauthplaygroundapplication",
            "cli_client_id": "go-cli",
            "clie_client_secret": "abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPOnmlijhoauthplaygroundapplication",
            "rs_client_id": "reporting-service",
            "rs_client_secret": "abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPOnmlijhoauthplaygroundapplication",
            "mlc_client_id": "mlc-service",
            "mlc_client_secret": "abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPOnmlijhoauthplaygroundapplication",
            "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"
        }
    },

And then include the --oauth pingfederate flag in moc-builder compose and it’ll connect 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 use case scenarios:

ModelOp Center leverages Oauth2 integration to fully support isolation of models--and all of their sensitive assets--by specified teams (groups). This 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 enterprise 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 a end-user perspective, they are only allowed to access and interact with the models, assets, and runtime with which they are permitted. This is carried across the ModelOp Center web interface, CLI, API’s, and Jupyter/RStudio plugins.

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

Admin user (superuser)

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

In the main landing page, they are able to see a summary of all items: 20 total models, 7 model life cycle processes, and 4 engines (runtimes):

Image Removed

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

Image Removed

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

Image Removed

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

In the landing page, therefore, they are only able to see a limited set of the resources available across the enterprise: 1 Model, 7 model life cycles, and 1 engine (runtime)

Image Removed

In the Models page, they are limited to viewing only the models that belong to their group, which is simply 1 model for now:

Image Removed

In the Runtimes page, they are limited to viewing only their Group’s runtimes, which is simply the “engine-aml” runtime:

Image Removed

Group access items that are isolated based on Oauth calls

As mentioned, behind the scenes, 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

OAuth2 usage within: (a) the CLI (b) UI (c) and API

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

• CLI

Steps:

• UI

• API

To provide further details, below are the filtering mechanisms supported through ModelOp Center’s Custom Mongo Template implementation for SpringDataRest and Custom annotations and request URL overwriting for JPA MethodNameQueries.