Integration details
...
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._alland 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.
Role org.onap.aai.traversal._all | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Role org.onap.aai.resources._all | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Open questions
- Who establishes the role - the service provider or the client? see the AAF diagram Jonathan Gatham, creator of AAF says: "No, you cannot assign roles. You can create a Role in your namespace. You can, however, create and grant Permissions to other Roles. You are free to grant Permission to any Role in the company, whether the role is managed by you, or someone else. It is painfully easy, therefore, to delegate role management to someone else... just grant specific permissions to their role."
- If the service provider - do we create multiple roles? e.g. a read-only one, read-write, client specific
- How fine-grained permissions do we want to create?
- How do we enable AAF since it has to have a connection to the windriver lab? Or we enable it only in special deployments?
...