Integration details
A&AI webservices resources and traversal are integrated with AAF through the Cadi filter. The request workflow looks as follows:
- The request is authenticated in AAF
- TODO: the request should be authorized in the future
- 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 type | instances | action |
---|---|---|
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 type | instances | action |
---|---|---|
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 |