Integration details

...

1. The request is authenticated in AAFTODO: the request should be authorized in the
2. futureThe request is authorized through a permission in AAF (see section: A&AI permissions)
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.

...

Users have roles assigned and each role has permissions.

A&AI permissions

...

There will be a separate permission for traversal and resources web services. Let's call these permissions org.onap.aai.resources and org.onap.aai.traversal. 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_advanced and org.onap.aai.resources_readonly and org.onap.aai.traversal_basic. These roles will be assigned to all users/applications which access A&AI web services.

Role name	Meaning
org.onap.aai.resources_all	read + write access to the resources web service
org.onap.aai.resources_readonly	read-only access to the resources web service
org.onap.aai.traversal_advanced	applications may issue basic and advanced queries in the traversal web service
org.onap.aai.traversal_basic	applications may issue only basic queries in the traversal web service

...