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 or execute specific actions, 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 (RWX - Read, Write, Execute ) 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 OIDC + AD/LDAP or OAuth2 OIDC interacting with SAML2 as idP) 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, ModelOp Center is designed to accommodate two distinct user categories or roles: Administrators and non-administrators. Administrators possess higher access privileges, enabling them to seamlessly navigate and interact with all resources available within ModelOp Center. In contrast, non-administrators are restricted to accessing resources that are exclusively associated with the specific business units or groups to which they belong. This segregation of access ensures that non-administrators can only engage with data and features that are relevant to their respective business units and responsibilities. This is carried across the ModelOp Center web interface, CLI, APIs, and Jupyter/RStudio plugins.
Additionally, ModelOp Center does not store any Customer business data sets; rather, ModelOp Center simply stores references to these data sets to leverage existing SecOps policies for these business data sets.
End User Flow (C2B)
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, from top Models By Business KPI to Issues by Business Unit.
Within the Business Models 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):
Within the Application Forms Configuration, Administrators are able to manage Application Forms
Within the Scores Configuration, Administrators are able to manage Scores Configurations
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. Hence, he/she only has access to models and associated assets assigned to Group 1.
In the Dashboard,therefore, they are only able to see a limited set of the resources available across the enterprise
In the Business Models Inventory, they are limited to viewing only the models that belong to their group which has 2 models.
In the Runtimes page, they are limited to viewing only their group’s runtimes, in this case current user has 2 runtimes associated to his group.
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 authorization. This approach does not tie ModelOp Center to a specific OAuth2 Authorization Server or Identity Provider (IdP) server implementation.
The following diagram provides a high level overview of the OAuth2 components and responsibilities existing inside ModelOp Center:
Flows represented in the diagram:
C2B (Client to Business) flow represented with gray tokens
B2B (Business to Business) flow represented with green tokens
Authorization Server:
The current architecture design supports different implementations of OAuth2 Authorization Server, including:
PingFederate
Amazon Cognito
Okta
Azure AD
Keycloak
Supported Access Tokens:
The current architecture design supports different token formats, including:
JWT
Opaque
The current architecture design supports different token validations, including:
JWKs
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 , document-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 (the aforementioned components represent the B2B flow).
Microservices defined as oauth2-clients are required to include a predefined scope in tokens, so that can be correctly differentiated from EndUser requests (C2B flow).
Pre-requisites
In order to successfully integrate ModelOp Center with OAuth2 with OIDC, the following pre-requisites should be provided:
OAuth2 Authentication Server Details ( .well-known configurations )
Token URI
Authentication URI
Issuer URI
Introspection URI
User Info URI (for opaque tokens)
SSO supported?
Token lifespan.
Access Token Details
Access token format.
Access token validation mechanism:
JOSE (JavaScript Object & Encryption)
JWK details.
Opaque:
Introspection URI.
Access token fields
Username or user_id
given_name
family_name
email
member_off (access group claim that can be a list or a comma separated string of values)
Admin group - default modelop
OAuth2 clients:
scope:
modelop_client
Minimum Required OAuth2 Clients
Proposed Client ID | Grant Types | Client Secret Required | Scopes | Redirect URLs |
gateway-service |
| ✔️ |
|
|
internal-client |
| ✔️ |
| |
go-cli |
| ✔️ |
| |
external-integration-client |
|
|
Extended OAuth2 Clients
Proposed Client ID | Grant Types | Client Secret Required | Scopes | Redirect URLs |
gateway-service |
| ✔️ |
|
|
model-manage |
| ✔️ |
| |
go-cli |
| ✔️ |
| |
mlc-service |
| ✔️ |
| |
reporting-service |
| ✔️ |
| |
document-service |
| ✔️ |
| |
jupyter |
|
|
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). 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 and certified 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…) |
|---|---|---|---|---|---|
Jane, Doe |
| ✅ | |||
John, Doe |
| ✅ | ✅ | ||
Admin One |
| ✅ | ✅ | ✅ | ✅ |
Admin Two |
| ✅ | ✅ | ✅ | ✅ |
Note: Specific configurations among OAuth2 IdPs may change.
API Enforcement of Group Based Access
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 with OIDC interacting with SAML2 ( as idP)
