Brivo Labs SAM - SCIM Gateway to Pi API Module Architecture

Brivo Labs would like to simplify user management in their product so that customer can more easily provision users from their existing systems into Brivo Labs system. Today customers must use a proprietary interface to perform CRUD operations on user resource in the system, we call this API "Pi". The barrier to integration for customers is quite high, requiring considerable development costs and effort. A solution that used a standard interface to user management would lower the barrier to integration and would allow customers to considerably reduce development costs and effort.

You are required to address the following in this challenge :

• Design a SCIM (gateway) interface on top of the Brivo Labs "Pi" API that can translate incoming requests compliant with the SCIM interface into corresponding requests on the Pi interface.
  • The SCIM specification version 1.1 was released in July 2012, the SCIM specification version 2.0 is currently under development. The architecture should target v1.1, but must include information about how the gateway will migrate to use v2.0 once it is released.
• We recognize that some translations are trivial whereas others are difficult; that some translations require additional semantic information not available today; and other features simply do not exist in "Pi" API. So you need to Perform a functional gap analysis between the capabilities of the Pi interface and the SCIM interface and produce a set of recommendations and suggested changes necessary in Pi to facilitate construction of the SCIM Gateway, The goal is for the Pi development team to incorporate these recommendations into the software.

SCIM Gateway

• Whereas the public facing API Management layer must expose a SCIM compliant interface, the SCIM gateway need not if the appropriate translations are in place in the API Management layer. That is, the burden of compliance can be at the API management layer, while the gateway APIs are optimized for translation.
• The solution can handle requests entirely within a single process or can handle requests among many coordinating processes with appropriate inter-process communication mechanisms between them.
• The SCIM will maintain a record of all the transactions passing through it.
• Authentication/Authorization does not have to be specified in detail; just reference it as an assumption in your documentation, and describe any SCIM-specific concerns/guidelines.

Data Store / Translation Metadata

• The solution can include its own data storage for configuration data or other metadata necessary to translate requests and work with Pi.
• The solution may use relational storage or unstructured storage, or both.
• The solution should be data store agnostic, include implementation notes if you feel there are data store selection implications.

Things you can assume about API Managment and Pi

• The solution will be hosted behind a 3rd party API management layer (such as Apigee or Mashery).
• The solution architecture can take full advantage of the services provided by the API management layer.
• Each tenant will be assigned a unique API key and API secret by the API management layer. The key/secret is validated by the API management layer and only properly authenticated requests are forwarded to the SCIM Gateway.
• The API key will be included in the HTTP headers of incoming requests and can be used as a unique key to index that tenant.
• Authentication is assured between the API management layer and the SCIM Gateway, the solution need not address scenarios such as the API management layer being impersonated or invalid requests arriving outside the API management layer.
• Facilities of the API management layer should be considered with respect to API versioning. The architecture can assume that API management layer will reroute requests or augment headers in order to facilitate API versioning.
• The solution should honor the Pi security model with respect to tenant activities. That is, each tenant shall have a corresponding Pi user. Requests to Pi will be in the context of the Pi user associated with that tenant.
• The solution need not include mechanism to throttle requests to Pi. The Pi servers will be sufficiently scaled out to handle the volume of traffic from the SCIM Gateway.
• The gateway should be resilient to recoverable communications errors.

General Guidance

The following items are general guidance we received from client but does not neccesserily be handled in the deliverables of this challenge :

• The solution shall support multiple tenants with per-tenant data isolation.
• The solution shall run in a cloud environment: cloud services, cloud storage, cloud scale & pay only for what you use. The overall operational costs for running the solution should follow typical cloud computing costs with respect to hosting, storage and network traffic.
• The solution shall support at least 10,000 tenants.
• The solution shall support at least 100,000 transactions (HTTP requests), per tenant, per day.
• The solution shall support at least 250 transactions concurrently, per second.
• The solution shall be designed such that additional scale units (nodes/servers/data stores) can be added on demand to increase capacity at near linear scale.
• The solution shall support 99.9% availability or better.

Details about the SCIM standard and specifications can be found at http://www.simplecloud.info/ Documentation for the "Pi" API documentation is provided in challenge forums.