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 web services. Let's call these permissions 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. These roles will be assigned to all users/applications which access A&AI web services.

Open questions

1. Do we create multiple roles? e.g. a read-only one, read-write, client specific