The Permission Type Registry
Permission Types are grouped into the Permission Type Registry with each Permission Type allowing for extendable methods of identifying permissions.
When an operation is initiated, binding permissions at each DOF component determines whether the operation is allowed to be transmitted through that component. Binding permissions are permission type 1 in the Permission Type Registry. A binding permission consists of four parts that determine what the permission allows:
- actions
- object identifiers
- interface identifiers
- attributes
When adding a binding permission with the domain management tool, the syntax is as follows (the color highlights are added for reference):
<1:actions:oids:iids:attributes>
Actions
Actions determine which types of operations are allowed. Each action can be specified by its corresponding letter (* is used for all actions).
Note: These actions are similar to Linux file permissions.
- Read (r) – Allows get and subscribe operations
- Write (w) – Allows set operations
- Execute (x) – Allows invoke operations
- Session (s) – Allows session operations
- Provide (p) – Allows provide operations
Object Identifiers
This is a list of allowed object identifiers. Each identifier is written in standard OID format without separators between entries. The * means any object identifier is valid.
OID Classes are listed in the OID Class Registry. The OID Class defines the format of the OID and prevents aliasing between different unique object data (in these examples we use Class:3, which represents the DOF OID for “email”).
Example: [3:john@tech-services.opendof.org] [3:bob@tech-services.opendof.org]
Interface Identifiers
This is a list of allowed interface identifiers. Each identifier is written in standard IID format without separators between entries. The * means any interface identifier is valid.
Example: [1:{0100000E}][1:{0100003C}]
Interface Identifiers are covered in DOF Object Model Training.
Attributes
This is a list of required attributes the object identifier must contain. The attribute can be specific and specifies the attribute type and data required. The attribute can also specify only the type of the attribute without requiring specific data. If there are no attribute requirements, leave this section blank.
Example: (0) – this means the provider attribute is required, but no specific data is required.
Example: (0)(1) – this means the provider and session attribute is required, but no specific data is required.
Usage Examples:
<1:xs;[3:statusManager@tech-services.opendof.org];[1:{0100000E}][1:{0100003C}];(0)>
This is a binding permission that:
- allows invoke and sessions operations
- works only with oid [3:statusManager@tech-services.opendof.org]
- works only with iid [1:{0100000E}] or [1:{0100003C}]
- requires the provider attribute
<1:p;*; [1:{0100000F}];(0)(1)>
This is a binding permission that:
- allows provide operations
- works with any oid
- works only with iid [1:{0100000F}]
- requires the provider attribute and the session attribute
<1:r;[3:statusManager@tech-services.opendof.org]; *;>
This is a binding permission that:
- allows read or subscribe operations
- works only with oid [3:statusManager@tech-services.opendof.org]
- works with any iid
- requires no attributes