Today’s world technology innovations have made collaboration easier than ever before, but different groups through the organization throughout organizations need to have access to shared and restricted information in a secured and centralized way, and 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, ensuring . 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 runtime runtimes with which they are permitted. This is carried across the ModelOp Center web interface, CLI, API’sAPIs, 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 authentication authenticated user details flow from PingDirectory to Ping Federate to be assembled, Ping Federate gathered 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, as long along with additional metadata.

4. Access JWT token gets issued to ModelOpCenterModelOp Center.

5. ModelOp center 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:

Image Removed

Image Removed

Image Added

Image Added

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:

Code Block

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

Code Block
language bash
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.