...
There will be a separate permission for traversal and resources web services. Let's call them 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. This role These roles will be assigned to all users/applications which access A&AI web services.
| Role org.onap.aai.traversal.all |
|---|
| 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 |
|
| Role org.onap.aai.resources.all |
|---|
| 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 |
|
Open questions
- Do we create multiple roles? e.g. a read-only one, read-write, client specific
