Skip to main content

meshcloud OSB API Profile

The OSB API Specification itself is a generic protocol and allows extension for specific implementations. OSB Services platform uses these extensions to allow service brokers to receive metadata from meshStack, control how their services are presented and made available in the marketplace as well as how they are to be billed.

The OSB API Spec allows platforms to define various extensions as part of a Profile.

Originating Identity Header​

OSB Services platform sets the X-Broker-API-Originating-Identity header to contain a Json Web Token (JWT) with the meshStack user id as well as the euid.

X-Broker-API-Originating-Identity: meshmarketplace eyJ1c2VyX2lkIjogInRlc3R1c2VyIiwgInVzZXJfZXVpZCI6ICJ0ZXN0VXNlckV1aWQifQ==

Decoding this JWT results in the following value:

{
  "user_id": "testuser",
  "user_euid": "testUserEuid"
}

Context Object​

Old mane of OSB Services platform is meshMarketplace, so by now you will stil see an old name "meshMarketplace" to configure this platfrom

OSB Services platform defines its own context objects for service provisioning requests. For the convenience of the service broker, the OSB Services platform delivers the following information:

{
  "platform": "meshmarketplace",
  "customer_id": "testCustomer",
  "project_id": "testProject",
  "auth_url": "https://{mesh-hostname}/auth/realms/meshfed/protocol/openid-connect/auth?client_id=1d4ad6d8-dfaa-4913-9c12-fd64b42a5c8d&response_type=code&redirect_uri={redirect_uri}&nonce={nonce}&state={state}",
  "token_url": "https://{mesh-hostname}/auth/realms/meshfed/protocol/openid-connect/token",
  "permission_url": "http://{mesh-hostname}/serviceInstances/c48d065b-a123-4a1e-8021-2965928d022d/permissions"
}

auth_url, token_url and permission_url will be null, unless the service broker's catalog specifies a dashboard client.

It is recommended that Service Brokers store this information as it allows platform engineers to more easily identify links between service instances and projects when handling support requests or monitoring service operation.

Catalog Metadata​

The OSB API Spec defines free-form metadata fields in the service catalog for service instances and plans. By providing specific metadata as outlined in the next sections, service brokers can instruct the OSB Services platform to provide specific functionality for their services, such as metering.

The conventions used by OSB Services platform are very similar to official OSB Profile metadata conventions for Cloud Foundry and Kubernetes.

Cost Information​

The OSB profile also contains properties to provide cost information via the OSB catalog. Besides showing this information to the user of the meshMarketplace, this information is also used by meshStack metering. That means cost information provided via the OSB catalog will be used to calculate costs for used services by meshStack metering.

Please review the meshMarketplace Metering documentation for more details.

Service Instance / Binding Parameters​

The OSB Services platform supports JSON schema for custom parameters used for service instance creation and service binding. The support of JSON schema is part of the OSB spec. Delivering JSON schema information allows the OSB Services platform UI to assist users in crafting proper parameters by rendering a user interface based on the content of the JSON schema. meshstack uses an open-source library to achieve this result. If you want to learn more about how to render the JSON schema into a UI, including all the edge-case possibilities, you can take a look at the library's GitHub repository. Below is an example of a JSON schema which should give you an idea of what's possible and how.

Please be aware that the OSB Services platform UI currently only supports version draft-04 of the JSON schema specification.

Service Instance JSON Schema Example​

{
  "type": "object",
  "properties": {
    "securityContact": {
      "type": "string",
      "title": "Security Contact",
      "description": "Who is the security responsible person for this service instance?",
      "default": "person@example-company.com"
    },
    "serviceType": {
      "type": "string",
      "title": "Service Type",
      "description": "Describes where the services faces its endpoints",
      "oneOf": [
        { "description": "Internal", "enum": ["int"] },
        { "description": "External", "enum": ["ext"] }
      ]
    },
    "externalRegistrationNumber": {
      "type": "string",
      "title": "External Registration Number",
      "description": "The external registration number which is required for externally facing services. The number should be exactly 5 digits. If not sure what number to pick, please go to help.example.com/external-registration-number.",
      "pattern": "^[0-9]{5}$",
      "visibleIf": {
        "serviceType": ["ext"]
      }
    }
  }
}

Things to keep in mind​

  • The order in which the JSON schema properties are shown is determined by the order of the properties within the JSON schema. Looking at the example, the ordering of UI inputs would be securityContact, serviceType and then externalRegistrationNumber.
  • It is possible to conditionally hide certain properties, depending on the values of other properties. Given the example JSON schema, externalRegistrationNumber will only be visible when the serviceType value is equal to ext.
  • The control that is rendered is dependent on data of the schema property itself. If you want, you can override this behavior by filling the widget property. Read more on widgets here.
  • If the value of a certain JSON schema property is not clear from the surface, don't forget that you can use the description for extra contextual information such as Wiki links or contact information.
  • It is possible to enforce certain patterns. This can be done by providing a Regular Expression in the pattern property. externalRegistrationNumber demonstrates this by enforcing the use of exactly five digits (0-9) as a value.