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

« Previous Version 5 Next »

Integration details

A&AI webservices resources and traversal are integrated with AAF through the Cadi filter. The request workflow looks as follows:

  1. The request is authenticated in AAF
  2. TODO: the request should be authorized in the future
  3. If the request passes all the checks (authentication and in the future authorization), it is forwarded to the A&AI servlet which handles the web services.

The AAF model

Permissions in AAF are triplets - type, instance, action.

  • Type: core name of the permission
  • Instance: the object that is being interacted
  • Action: What is happening with this object

Users have roles assigned and each role has permissions.

A&AI permissions proposal

There will be a separate permission for traversal and resources. Let's call them org.onap.aai.resources.access and org.onap.aai.traversal.access. For now we will not distinguish between different objects we could affect, so the instance will always be "*" meaning everything. Actions will be mapped to HTTP verbs - GET, PUT, POST, DELETE, PATCH.

For a seemless transition to AAF, the first roles we use for our clients will be called org.onap.aai.resources.all and org.onap.aai.traversal.all and will contain all read and write permissions for A&AI web services. This role will be assigned to all users/applications which access A&AI web services.


Permission typeinstancesaction
org.onap.aai.resources.access*get
org.onap.aai.resources.access*put
org.onap.aai.resources.access*post
org.onap.aai.resources.access*delete
org.onap.aai.resources.access*patch




Permission typeinstancesaction
org.onap.aai.traversal.access*get
org.onap.aai.traversal.access*put
org.onap.aai.traversal.access*post
org.onap.aai.traversal.access*delete
org.onap.aai.traversal.access*patch
  • No labels