Today’s world have made collaboration easier than before, different groups through the organization 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 just 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 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 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 with which they are permitted. This is carried across the ModelOp Center web interface, CLI, API’s, and Jupyter/RStudio plugins.
Base Group Access full life cycle
Groups are being defined at their existing processes and systems for user management (AD/LDAP).
Ping Directory interacts with AD/LDAP to retrieve current authenticated user details.
Current authentication user details flow from PingDirectory to Ping Federate to be assembled, Ping Federate gathered 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 with additional metadata.
Access JWT token gets issued to ModelOpCenter.
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
Get Token URI.
Authentication URI.
Issuer URI.
Access Token Details
Access token format defined.
Access token validation mechanism:
JOSE (JavaScript Object & Encryption)
JWK details.
Opaque:
Introspection URI.
Access token fields.
Username or user_id
First_name
Last_name
Email
Access group list.
Oauth2 clients required
Proposed Client id | Grant_types | client_secret ( temp dev ) | scope | Redirect URL |
gateway-service |
| abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO | openid,profile,email,modelopcenter | http://{RESOURCE_LOCATION}/login/oauth2/code/gateway-service |
model-manage |
| abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO | openid,profile,email,modelopcenter | |
go-cli |
| abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO | openid,profile,email,modelopcenter | |
mlc-service |
| abc123DEFghijklmnop4567rstuvwxyzZYXWUT8910SRQPO |
| |
reporting-service |
| 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 | ||
|---|---|---|
| ||
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:
StoredModels
DeployableModels
DeployedModels
ModelTestResutls
ModelBatchJobs
EngineNotifications
ModelNotifications
ModelTestNotifications
ModelReviewNotifications
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.
