Skip to end of metadata
Go to start of metadata

Problem: SMS (Service Management Service) configuration can currently only be changed by using the CLI (and it’s associated JAX-RPC web services), the Client SDK, or by using the JATO Console. In order to make this more flexible, we are adding REST endpoints in order to be able to manipulate the configuration for all services that would otherwise be editable in the console. This is not intended to be done by exposing the existing SMS structure directly as REST endpoints, but to produce a more consumer-friendly API for it.


Assumptions: The only types of service schema we need to support are Global and Organisation (realm). We would also need to support properties (i.e. server config). The Schema element of the sms.dtd allows the following elements:


Global?, Organization?, Dynamic?, Policy?, User?, Group?, Domain?, Generic*, PluginInterface*


Policy (legacy policy framework), User (attributes of a user) and Group (attributes of a group) are easy to rule out, and through looking at the uses of the remaining elements, it is clear that this assumption is reasonable.


Realm SMS Endpoints


For realms we have the following types of SMS config:

  • Realm settings

  • Services

  • Federation

  • Authentication settings

  • Authentication Modules

  • Authentication Chains


STS Instances are not needed as they already have their own CREST management endpoints.


To support these, the following endpoints will be created:

  • /json/{realm}/realm-config - Singleton for realm settings (enabled, aliases, etc.)

  • /json/{realm}/realm-config/services/{name} - Singletons/Collections for all possible realm service settings - when the service has a subschema, it should be a collection, and otherwise a singleton

  • /json/global-config/federation/circlesoftrust - Collection resource for federation circles of trust

  • /json/global-config/federation/entityproviders - Collection resource for federation entity providers

  • /json/global-config/federation/saml1x - Singleton resource for local site properties

  • /json/global-config/federation/saml1x/trustedpartners - Collection resource for SAML 1.x trusted partners

  • /json/global-config/federation/... - API for configuring federation

  • /json/{realm}/realm-config/authentication - Singleton for realm authentication settings (default chains, etc.)

  • /json/{realm}/realm-config/authentication/modules - Collection of module configuration

  • /json/{realm}/realm-config/authentication/chains - Collection of module chains (with future-proof name)


Global SMS Endpoints


At the global level, we have the following types of SMS config:

  • Authentication Module defaults

  • Services

  • Servers

  • Sites

  • Properties


To support these, the following endpoints will be created:

  • /json/global-config/authentication - Global authentication settings (appears as Core in the Configuration/Authentication tab)

  • /json/global-config/authentication/modules/{name} - Singleton for authentication module global settings and defaults

  • /json/global-config/services/{name} - Singletons/Collections for global service settings - when the service has a subschema, it should be a collection, and otherwise a singleton

  • /json/global-config/sites - Collection resource for sites

  • /json/global-config/servers - Collection resource for servers

  • /json/global-config/platform/servers/server-default/properties/{tab} - Default property values for a tab of properties (server-default is the ID of the default server template, so this would actually be handled by the following route)

  • /json/global-config/platform/servers/{id}/properties/{tab} - Singleton for server’s properties


Generic Services


Even the newest of SMS global/realm services do not have particularly URI-friendly names, so these would be translated by a mapping to more friendly names.


Services are singletons, and it is proposed that on read will return a 404 if they have not been provisioned. An action for provision will be created, as singleton resources do not support create.



Schema Attributes

  • Realm attributes will appear as top-level JSON attributes.

  • Global (default) attributes will be grouped under the top-level JSON attribute, “defaults”.

  • Dynamic attributes will be grouped under the top-level JSON attribute, “dynamic”.



Default values


All SMS schemas support default values. In order to support this in the REST API, an action, “template”, has been created that will return a state object with defaulted values, that can be populated with required values and sent back from creation.

Schema


All SMS schemas support an action, “schema”, that will return the schema in the JSON Schema format, http://json-schema.org/documentation.html. Consuming clients can use this to draw a dynamic UI based on the type of each attribute.

  • No labels