- 1. a role is where users and permissions meet; permissions are not granted directly to users, rather a perm is granted to a role and users are added to the role
- 2. a role contains 0 or more permissions
- 3. a role contains 0 or more users or APPID identities
- 4. note that role memberships have an expiration date. The owner of the namespace must re-approve all role memberships periodically. All approval requests, role renewal reviews, credential expiration, etc, emails will go to the namespace owner. If the namespace owner doesn't act upon these emails, users/appid’s will lose their permissions. Applications will break. Restoring lost permissions is the responsibility of the namespace admins, not any AAF support tier.
-
-namespaces contain 1 or more permissions
- 1. other than the access permissions discussed below, AAF does not care about permissions
- 2. AAF does not interpret application-specific permissions; in other words, it's up to the applications developers to create a permission scheme.
- 1. the general usage pattern is that an application will ask for all permissions associated with a user
- 2. locally, the application interprets what the presence or absence of a permissions means
-by default, every namespace has 2 "access" permissions:
- 1. a read/write permission, for instance "org.onap.test.access * *"
- 2. a read only permission, for instance "org.onap.test.access * read"
- - by default, every namespace has an admin role, for instance "org.onap.test.admin"
- 1. the admin role contains the read/write permission for the namespace; if you delete the admin role, or the read/write permission from the role, your admins will have no access to your namespace. This is bad.
+ #. a role is where users and permissions meet; permissions are not granted directly to users, rather a perm is granted to a role and users are added to the role
+ #. a role contains 0 or more permissions
+ #. a role contains 0 or more users or APPID identities
+ #. note that role memberships have an expiration date.
+
+ - The owner of the namespace must re-approve all role memberships periodically.
+ - All approval requests, role renewal reviews, credential expiration, etc, emails will go to the namespace owner.
+ - If the namespace owner doesn't act upon these emails, users/appid’s will lose their permissions. Applications will break.
+ - Restoring lost permissions is the responsibility of the namespace admins, not any AAF support tier.
+
+Namespaces contain 1 or more permissions
+ #. other than the access permissions discussed below, AAF does not care about permissions
+ #. AAF does not interpret application-specific permissions; in other words, it's up to the applications developers to create a permission scheme.
+
+ - the general usage pattern is that an application will ask for all permissions associated with a user
+ - locally, the application interprets what the presence or absence of a permissions means
+
+By default, every namespace has 2 "access" permissions:
+ #. a read/write permission, for instance "org.onap.test.access \* \*"
+ #. a read only permission, for instance "org.onap.test.access \* read"
+
+By default, every namespace has an admin role, for instance "org.onap.test.admin"
+ #. the admin role contains the read/write permission for the namespace
+
+ - if you delete the admin role, or the read/write permission from the role, your admins will have no access to your namespace. This is bad.
+