ModelOp Center Security - Oauth2 Integration

Owned by Miguel Rosas
Last updated: Sept 21, 2020 by Dave Trier
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.

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.

Group Base Access full life cycle

 

  1. Groups are being defined at their existing processes and systems for user management (AD/LDAP).

  2. Ping Directory interacts with AD/LDAP to retrieve current authenticated user details.

  3. Current authenticated user details flow from PingDirectory to Ping Federate to be assembled, Ping Federate gathers current authenticated user details coming from one or multiple sources and builds the access token to be issued, inserting incoming user data inside the JWT token payload as claims, along with additional metadata.

  4. Access JWT token gets issued to ModelOp Center.

  5. ModelOp Center uses the content inside the JWT claims to perform granular enterprise authorization in order to validate incoming requests from end user, using Group Base Access to define what data can be accessed and Granted Authorities to validate if the method request is granted to the given user.

 

 

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 Authentication through Ping Federate:

 

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

Within the Models page, 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 (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 permitted for 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)

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

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

 

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

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

abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO

openid,profile,email,modelopcenter

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

abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO

openid,profile,email,modelopcenter

 

 

go-cli

  • Refresh_token

  • Resource Owner Password Credentials

abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO

openid,profile,email,modelopcenter

  •  

mlc-service

  • Client_credentials

  • Resource Owner Password Credentials

  • Access Token Validation (Client is a Resource Server )

  • Refresh Token

abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO


openid,profile,email,modelopcenter

  •  

reporting-service

  • Client_credentials

  • Resource Owner Password Credentials

  • Access Token Validation (Client is a Resource Server )

  • Refresh Token

abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO

openid,profile,email,modelopcenter

  •  

 

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:

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:

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



 

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