Interface RoleRequest._FinalStage
- All Known Implementing Classes:
RoleRequest.Builder
- Enclosing class:
RoleRequest
-
Method Summary
Modifier and TypeMethodDescriptionaddAllScopes(List<ScopeClause> scopes) additionalProperties(Map<String, Object> additionalProperties) additionalProperty(String key, Object value) addScopes(ScopeClause scopes) ThePOST /v1/auth/token/assumeentitlement grant: which values, perscope:<namespace>, a holder of THIS role may assume via/assume.build()description(String description) description(Optional<String> description) An optional free-text description of what the role grants.scopes(List<ScopeClause> scopes) The role's permissions, as one or more scope clauses.
-
Method Details
-
build
RoleRequest build() -
additionalProperty
-
additionalProperties
-
description
An optional free-text description of what the role grants.
-
description
-
scopes
The role's permissions, as one or more scope clauses. Each clause has
allowed_actions(a list of permitted verbs),data_scope(an attribute filter that restricts which records the actions apply to), and an optionalgranted_capabilitieslist. An action is permitted if any clause allows that action and that clause's data scope matches the target record — with one caveat worth knowing before you usegranted_capabilities: a clause naming a capability this release does not recognize is denied ENTIRELY, so itsallowed_actionsstop applying too. To include records whose ownership field is null (account-level shared records), addnullto the allowed values for that field. One exception applies when creating an identity entity: the entity's own-namespace dimension (scope:<namespace>) takes the value of the ID the server is about to generate, so no clause written beforehand could name it, and that one dimension is exempt from the match onPOST /v1/entities/{namespace}. It is matched normally on every read, update, and delete — so a clause whose data scope names only that dimension does not restrict what you may create, and an entity created under one may fall outside it once it exists. -
addScopes
-
addAllScopes
-
assumable
The
POST /v1/auth/token/assumeentitlement grant: which values, perscope:<namespace>, a holder of THIS role may assume via/assume. Role-level (unlikedata_scope, which is per-clause) — this is a deliberately separate question from whatscopespermits reading or writing; holding broaddata_scopereach in a namespace does NOT by itself grant assuming any value in it. The principal (userId) can never be named — it is never assumable. Each value list accepts a plain literal,${{ under.self.userId }}, or${{ member.scope.<namespace>[:level] }}— never${{ under.self.scope.<namespace> }}(it resolves against the caller's CURRENT value for a namespace/assumecan itself change, so what it admitted would depend on what was last assumed; that form stays valid indata_scope, where it's re-derived per write), a bare${{ self.<dim> }}, or${{ any }}, all rejected at authoring time. Omitting the field grants no assumption of anything, the safe default. -
assumable
-