Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

An Authenticated Feed in ONAP refers to a Data Router (DR) Feed with the following characteristics:

  • applications implementing a DR publisher will authenticate when connecting to a Data Router instance using the Data Router Publish API
  • applications implementing a DR subscriber will validate presented credentials upon delivery of files from DR
  • DR authentication uses Basic Authentication.  There are two user store options for this:
    1.  local user store - user name and password are stored locally in DR database.
    2. AAF user store - user name and password are stored in AAF component, and DR validates user credentials using the AAF API.  When AAF credentials are used, the following checks are performed:
      • authenticate the client
      • authorize the client for the action (pub) on the specific topic


In order to properly provision an Authenticated Feed using AAF, the AAF permissions for managing feed namespaces, creating feeds, and creating and granting the permissions for client actions on a specific feed, all must be coordinated using various APIs.  This functionality will be provided by the DMaaP Bus Controller API in El Alto Release, and is intended to used as a convenient way for applications to use DMaaP resources like Authenticated Feeds.

This article will describe how to provision an Authenticated Feed using the DMaaP Bus Controller in ONAP Dublin.

There are 3 ways to utilize the DMaaP Bus Controller API:

  1. Static - some Feeds are known in advance as part of Release planning and need to be provisioned in all ONAP deployments.  These are provisioned during the DMaaP DR deployment process.
  2. DCAE - some Feeds are needed by microservices managed by DCAE.  These topics are provisioned by the DMaaP Plugin used in DCAE deployments.
  3. On Demand - a user could use an http client (e.g. curl) to provision a Feed.   This might be needed in a dev environment, or in some other deployment scenario.

The remaining sections describe each of these methods.

Prerequisites

In Dublin, there are no pre-requisites to Feed Provisioning.

When AAF Authentication is supported by Bus Controller API in El Alto, the following pre-requisites will apply:

  1. (Future) The AAF Identity used by the client application needs to exist in the AAF instance that DMaaP components are referencing.  In a standalone ONAP deployment, this means that AAF must be deployed and the AAF bootstrap provisioning must have successfully completed.  An application should follow the directions from the AAF team for establishing a new Identity that is included in future AAF bootstraps.
  2. (Future) The Identity used by Bus Controller (i.e. dmaap-bc) must be granted the necessary permissions to create topics and AAF Roles associated with the topics.  This makes Bus Controller a "trusted provisioner".  The AAF bootstrap should include all the steps necessary to satisfy this prerequisite.
  3. (Future) The Identity used by the client to the Bus Controller API must be authorized to invoke the /feeds API.  AAF Authentication and Authorization of usage of the Bus Controller API assures that only authorized clients will make provisioning changes.

Static

An Authenticated Feed created using the Static method is provisioned during the deployment of the dmaap-dr-prov component.  A post-install job associated with the dmaap-dr-prov chart will provision all feeds found in a well known ConfigMap.  To add a new feed using this method, simply add a new file to the following OOM directory:  oom/kubernetes/dmaap/components/dmaap-dr-prov/resources/feeds

The format of this file should be a valid JSON request to the Bus Controller  POST /topics API

The post-install job runs the dbc-client container, which is authorized to make Bus Controller API calls.

NOTE: Any ONAP component could utilize this method (i.e. post-install script reading a ConfigMap) to tie provisioning of an Authenticated Feed to their component deployment.   This would introduce a deployment ordering dependency on DMaaP, but that probably already is necessary for normal operations.

DCAE

An Authenticated Feed created using the DCAE method is provisioned using the Cloudify DMaaP Plugin during deployment of the microservice.  The details about the topic and application Identity are specified in the application blueprint.  (Confirm)

NOTE: the Cloudify DMaaP Plugin is not committed for Dublin, but is a stretch goal.

On Demand

An Authenticated Feed created using the On Demand method is always available in an ONAP DMaaP deployment.  A user can use an http client application such as curl or postman to make a request to the Bus Controller  POST /feeds API.


  • No labels