Security - SAML 2.0 IdP Integration

ModelOp Center integrates with SAML 2.0 to enable enterprise-grade authentication and access control, allowing isolation of models by authorized groups.

The saml-support-service is an optional microservice in the ModelOp Center install. This service is the bridge between components using SAML 2.0 and components using OAuth 2.x. The roles of the saml-support-service include:

1. SAML 2.0 Service Provider (SP)

2. OAuth 2.x Authorization Server (AS).

When in the role of SP, the saml-support-service is responsible for initiating user authentication with a SAML request to the SAML identity provider (IdP). After receiving the SAML assertion, the saml-support-service validates it and parses the necessary information: the username, user attributes, etc.

When in the role of AS, the saml-support-service is responsible for creating OAuth 2.x tokens. The payload of the OAuth 2.x tokens will include the parsed necessary information from the SAML assertion.

The implementation of both roles is done using Spring.

Open

High-level architecture that represents the use of SAML 2.0 and OAuth 2.x components

ForgeRock: The SAML IdP responsible for authenticating users on behalf of ModelOp Center as well as providing necessary user information as part of the SAML assertion.

For a successful integration of ModelOp Center with a SAML 2.0 IdP, the following prerequisites must be met:

• ForgeRock 7.1.x

1. Entity providers:

   1. Configure ForgeRock as hosted IdP

      1. Assertion Content

         1. Sign logout request

         2. Sign logout response

      2. Assertion Processing

         1. SAML Attribute*:

            1. uid

            2. givenName

            3. lastName

            4. email

            5. groups**

   2. Configure saml-support-service as remote SP

      1. Assertion Content

         1. Sign logout response

2. Circle of Trust

   1. Configure a circle of trust between the aforementioned entity providers

3. Required information for ModelOp Center configuration:

   1. ForgeRock URL

   2. ForgeRock metadata URL

   3. ForgeRock logout URL

1. Signing credentials

   1. Configure the private key and certificate for signing SAML requests

2. SP metadata file***

By default, the saml-support-service comes preconfigured with three clients ready for use:

1. gateway-service

2. internal-client

3. dynamic-registration-client

The gateway-service and internal-client cover all scenarios for successful integration with ModelOp Center. However, if additional clients are needed, the saml-support-service supports dynamic client registration. This feature is disabled by default.

To enable it, please follow these steps:

1. Add the dynamic-registration-client profile to the saml-support-service, (optionally you can add h2 profile in order to add h2 as base DB for the dynamic-clients being registered.)

2. Run the following cURL commands to dynamically register a new client

   1. Request an initial access token

      1. curl "<SAML-SUPPORT-SERVICE-URL-PLACEHOLDER>/oauth2/token" -k -i \ --data-urlencode 'client_id=dynamic-registration-client' \ --data-urlencode 'scope=client.create' \ --data-urlencode 'grant_type=client_credentials' \ --data-urlencode 'client_secret=!modelop_reGistrar-secret'

   2. Register a new client - note: Client-id and client-secret will be autogenerated.

      1. curl --location '<SAML-SUPPORT-SERVICE-URL-PLACEHOLDER>/connect/register' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer <INITIAL-ACCESS-TOKEN-PLACEHOLDER>' \ --data '{ "client_name": "new-client", "scope": "modelop_client", "token_endpoint_auth_method": "client_secret_post", "grant_types": ["client_credentials"], "redirect_uris": ["http://dummy.com"] }'

   3. Request an access token using the newly registered client , client-id and client-secret will be extracted from the response of the previous endpoint.

      1. curl "<SAML-SUPPORT-SERVICE-URL-PLACEHOLDER>/oauth2/token" -k -i \ --data-urlencode 'client_id=<CLIENT-ID-RETURNED-IN-RESPONSE-PLACEHOLDER>' \ --data-urlencode 'scope=modelop_client' \ --data-urlencode 'grant_type=client_credentials' \ --data-urlencode 'client_secret=<CLIENT-SECRET-RETURNED-IN-RESPONSE-PLACEHOLDER>'

With the dynamic-registration-client profile active, both the default clients and any newly registered clients will be stored in an H2 database. The data in this database will persist even if the saml-support-service is restarted.

By default, all passwords are encoded using the bcrypt algorithm before being stored in the database. To update a password, you must first encode it with bcrypt and then update the client record with the new value.

1- Encode password with bcrypt and 12 rounds , the next python helps with it

Open

e.g:

In this example we are encoding the password my-cool-password

2- Grab the encoded password from Hashed password and extract the value inside the single quotes

$2b$12$cY1M0uA0CVbwUKOTCydrXebTaIot2VdbQssIToorDmxkakF79iEta

3- Append the prefix {bcrypt} to it e.g: {bcrypt}$2b$12$cY1M0uA0CVbwUKOTCydrXebTaIot2VdbQssIToorDmxkakF79iEta

4- Use the updated value for CLIENT_SECRET for the client you want to update password.

In the next example we are updating user with CLIENT_ID=123

5- Once the update is successfully completed for the client with client_id=123, the client can then use the new password my-cool-password to obtain access tokens.

The OAuth 2.x Authorization Server does NOT support the following grant types:

1. Password Grant Flow

   1. Impacts ModelOp CLI

2. Implicit Grant Flow

   1. Impacts Jupyter and Tableau integrations