ModelOp Center Security - Oauth2 Integration

Owned by Dave Trier
Last updated: Feb 23, 2022 by Miguel Rosas
7 min read

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.

 

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: 20 models, 7 model life cycle processes, and 4 engines (runtimes).

 

Within the Production Model 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: 1 model, 7 model life cycle processes, and 1 runtime.

 

In the Production Model Inventory, they are limited to viewing only the models that belong to their group which has 1 model.

 

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

 

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 )

  1. Token URI

  2. Authentication URI

  3. Issuer URI

  4. Introspection URI

  5. User Info URI (for opaque tokens)

  6. SSO supported?

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

  • Client_credentials

  • Resource_Owner_Password_Credentials

  • Access_Token_Validation (Client is a Resource Server)

  • Refresh Token

CLIENT_SECRET

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

openid,profile,email

 

 

*mlc-service

  • Client_credentials

  • Refresh_token

CLIENT_SECRET

openid,profile,email

 

*reporting-service

  • Client_credentials

  • Refresh_token

CLIENT_SECRET

openid,profile,email

 

*document-service

  • Client_credentials

  • Refresh_token

CLIENT_SECRET

openid,profile,email

 

*modelop-runtime

  • Client_credentials

  • Refresh_token

CLIENT_SECRET

openid,profile,email

 

sagemaker-service

  • Client_credentials

  • Refresh_token

CLIENT_SECRET

openid,profile,email

 

spark-runtime

  • Client_credentials

  • Refresh_token

CLIENT_SECRET

openid,profile,email

 

tableau

  • Implicit

CLIENT_SECRET

openid,profile,email

 

go-cli

  • Client_credentials

  • Refresh_token

  • Resource Owner Password Credentials

CLIENT_SECRET

openid,profile,email

 

jupyter

  • Implicit

  • Client_credentials

CLIENT_SECRET

openid,profile,email

 

power-bi

  • Authorization_code

  • Refresh Token

CLIENT_SECRET

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", "mm_client_id": "model-manage", "mm_client_secret": "CLIENT_SECRET", "cli_client_id": "go-cli", "clie_client_secret": "CLIENT_SECRET", "rs_client_id": "reporting-service", "rs_client_secret": "CLIENT_SECRET", "mlc_client_id": "mlc-service", "mlc_client_secret": "CLIENT_SECRET", "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:

  1. StoredModels

  2. DeployableModels

  3. DeployedModels

  4. ModelTestResutls

  5. ModelBatchJobs

  6. EngineNotifications

  7. ModelNotifications

  8. ModelTestNotifications

  9. ModelReviewNotifications

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

 


Steps:

Step

Description

1

CLI client requests the list of models, without ACCESS_TOKEN

2

Gateway returns 403 - Forbidden access - requiring user Authentication

3

User input credentials, CLI-client, encrypt credentials before forwarding to Gateway

4

With received credentials, Gateway, request access on behalf CLI user, forwarding received user credentials plus own credentials using Resource_Owner_Password_Grant

5

Ping Directory, receives CLI user credentials and Gateway's GO-CLI's credentials and performs validation with Ping Directory

6

Ping Directory uses LDAP / AD or other preconfigured mechanism to validate credentials

7

Validation approved

8

Validation approved

9

Once Ping Federate has approved credentials, issues ACCESS_TOKEN

10

Gateway receives ACCESS_TOKEN issued, and forwards it to CLI-CLIENT

11

CLI client, receives ACCESS_TOKEN and saves it internally, to be included on further requests to ModelOp Center

12

Cli client requests the list of models, including ACCESS_TOKEN

13

Gateway asks Ping Federate for ACCESS_TOKEN validation

14

Ping Federate validates ACCESS_TOKEN

15

Gateway forwards request from CLI to Model-Manage including ACCESS_TOKEN

16

Model manage asks Ping Federate for ACCESS_TOKEN validation, before serving request

17

Ping Federate validates ACCESS_TOKEN

18

Model-manage generate and returns request response, (List of models)

19

Gateway forwards response to CLI Client

 

Within the UI

 

Within the API

To provide further details, shown below are the filtering mechanisms supported through ModelOp Center’s custom MongoTemplate implementation for Spring Data Rest, custom annotations and request URL overwriting for Spring Data JPA method named queries.