meshcloud OSB API Profile

The OSB API Specification itself is a generic protocol and allows extension for specific implementations. meshMarketplace 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

meshMarketplace 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

meshMarketplace defines its own context objects for service provisioning requests. For the convenience of the service broker, the meshMarketplace 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 operators 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 meshMarketplace to provide specific functionality for their services such as metering or allowing service instance sharing.

The conventions used by meshMarketplace 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.

Sensitive Services

Usually the meshMarketplace shows credentials of a Service Binding to the users, who have access to it. If the Service Broker requires a more secure handling of credentials, it can provide the sensitive metadata for the according service in the OSB catalog.

{
  "services": [{
    "id": "acb56d7c-XXXX-XXXX-XXXX-feb140a59a66",
    "name": "fake-service",
    "metadata": {
      "sensitive": true
    }
  }]
}

The meshMarketplace does not store any credentials provided by bindings on sensitive services. Instead, the meshMarketplace will only offer the credentials for download during the initial creation of the binding. The precondition for this to work is, that the creation of the binding is synchronous. Async bindings are not supported for sensitive services.

Tenant-Aware Services

A Service Broker can define its services to be tenant-aware by providing a tenantAware flag in service metadata of the service definition. Tenant-aware Services can receive special Service Bindings that provide the meshTenant context to the Service Broker using a special Bind Resource Object. When users create a tenant service binding in the meshMarketplace, they have to select a meshTenant. Only the meshTenants of the meshProject, which contains the Service Instance, can be selected.

In the service catalog it would like this:

{
  "services": [{
    "id": "acb56d7c-XXXX-XXXX-XXXX-feb140a59a66",
    "name": "my-service",
    "metadata": {
      "tenantAware": true
    }
  }]
}

Please review the Tenant-Services documentation for more details-

Sharable Service Instances

Service Instance Sharing must be activated by Service Broker via shareable flag on metadata of the service definition.

{
  "services": [{
    "id": "acb56d7c-XXXX-XXXX-XXXX-feb140a59a66",
    "name": "fake-service",
    "metadata": {
      "shareable": true
    }
  }]
}

Expiring Service Bindings

Additionally, the meshMarketplace supports expiring service bindings which can be used to force credential rolling. Service catalogs can specify service plans with expiring bindings by settings metadata.expiryDays to the number of days after which a service binding for a service instance based on this plan should be deleted. The meshStack regularly checks expiring service bindings, notifies users about upcoming expiration dates through the marketplace dashboard and enforces their deletion once they are expired.

Service Instance / Binding Parameters

The meshMarketplace supports JSON schema for custom parameters used for service instance creation and service binding. You can find the description of the schema in the OSB spec.

Delivering this schema information allows the meshMarketplace UI to assist users in crafting proper parameters.

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