📄 rfc3341.txt
字号:
When an application wants to delete the access entry associated with
an owner/actor combination, it sends a "set" element to the service
omitting the permitted actions, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='wilma@example.com' />
<recipient identity='apex=access@example.com' />
<data-content Name='Content'>
<set transID='2'>
<access owner='fred@example.com'
actor='*@example.com'
lastUpdate='2000-05-14T13:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
Rose, et. al. Standards Track [Page 7]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
The service immediately responds with a reply operation containing
the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<reply code='250' transID='2' />
</data-content>
</data>
S: <ok />
The service also immediately sends a set operation to the owner
attribute associated with the access entry, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<set transID='2'>
<access owner='fred@example.com'
actor='*@example.com'
lastUpdate='2000-05-14T13:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
Because there are no actions associated with this access entry, the
owner knows that the entry has been deleted.
Note that because access control supported limited wildcarding of
actors, deleting an access entry for a particular owner/actor
combination, may modify, rather than remove, permission. Because of
this, a special action, "all:none", is used.
Rose, et. al. Standards Track [Page 8]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
For example, consider these two access entries:
<access owner='fred@example.com'
actor='barney@example.com'
actions='core:data presence:subscribe presence:watch'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
Deleting the first access entry will not remove all permissions for
for the actor "barney@example.com".
Instead, the first access entry should be modified thusly:
<access owner='fred@example.com'
actor='barney@example.com'
actions='all:none'
lastUpdate='2000-05-14T13:20:00-08:00' />
3. Format of Access Entries
Each administrative domain is responsible for maintaining one or more
"access entries" for each of its endpoints and associated
subaddresses (regardless of whether those addresses are currently
attached to the relaying mesh).
A separate access entry is required for each actor or group of actors
for whom access permission is specified. Section 6 defines the
syntax for access entries. Each access entry has an "owner"
attribute, an "actor" attribute, an "actions" attribute, a
"lastUpdate" attribute, and no content:
o the "owner" attribute specifies the address (endpoint or
subaddress) associated with the access entry;
o the "actor" attribute specifies an entity or group of entities for
whom access permissions are specified, as described below;
o the "actions" attribute specifies the permissions granted to the
actor in the context of the owner; and,
o the "lastUpdate" attribute specifies the date and time that the
service last created or modified the access entry.
Rose, et. al. Standards Track [Page 9]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
An action is specified as a service/operation pair, e.g., the action
"presence:publish" refers to the "publish" operation of the
"presence" service. Two service values are reserved:
o "all" is used to refer to all services, e.g., "all:data"; and,
o "core" is used to refer to the service implemented by the relaying
mesh, e.g., the "core:data" permission is consulted by the
relaying mesh (c.f., Step 5.3 of Section 4.4.4.1 of [1]).
Further, two operation values are reserved:
o "all" is used to refer to all operations, e.g., "presence:all";
and,
o "none" is used to refer to no operations whatsoever, e.g.,
"all:none".
An actor is an APEX address and is specified using the "entity"
syntax specified in Section 2.2 of [1]. However, both the "local"
and "domain" parts may contain limited wildcarding:
o The "local" part is either:
* a literal string (e.g., "fred");
* a subaddress wildcard (e.g., "fred/*" or "apex=pubsub/*"); or,
* the value "apex=*", specifying all APEX services;
* the value "*", specifying any address other than an APEX
service.
o The "domain" part is either:
* a FQDN (e.g., "example.com");
* a domain wildcard (e.g., "*.example.com"); or,
* the value "*", specifying all administrative domains.
Note that in the case of a domain wildcard, the wildcard itself
matches zero or more subdomains, e.g., "*.example.com" matches
"example.com", "foo.example.com", "bar.foo.example.com", and so
on.)
Rose, et. al. Standards Track [Page 10]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
The following default entries are provided for each owner, but are
overridden by an explicitly supplied entry with the same actor value:
actor='local@domain' actions='all:all'
actor='apex=*@domain' actions='all:all'
actor='apex=*@*' actions='core:data'
actor='*@*' actions='all:none'
where "local@domain" specifies the owner associated with the access
entry.
For example, the explicit entry
actor='*@*' actions='core:data'
allows endpoints from any domain to use the relaying mesh to send
data to the owner, but does not override the default entry for
"apex=*@domain", which allows all APEX services in the owner's domain
access to all actions.
APEX endpoint names can legitimately contain the character '*', but
access entries use '*' to indicate wildcarding. Accordingly, the
two-character sequence '\*' is used to avoid ambiguity in the "actor"
attribute. Similarly, to explicitly specify an endpoint name
containing '\' in the "actor" attribute, the two-character sequence
'\\' is used.
Note that this convention is used only for the "actor" attribute of
the "get" operation and of the "access" entry that appears in the
"set" operation; however, this convention is not used in the "query"
operation, as this operation does not allow wildcarding.
For example, to specify the endpoint named as "a\b*c@example.com" in
the "get" operation or in an "access" entry, the string
"a\\b\*c@example.com" is used; but in the "query" operation, the
string "a\b*c@example.com" is used. (Of course, as name allocation
is a local matter, these complications can be avoided by the simple
expedient of not using endpoint names containing '*' or '\'.)
3.1 Finding the Appropriate Entry: Matching Owners and Actors
The use of actor wildcarding makes it possible for several access
entries to apply for a given owner/actor combination. When
determining which access entry to use when responding to the query
operation, the algorithm is:
o Consider only those access entries that are associated with the
given owner.
Rose, et. al. Standards Track [Page 11]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
o Consider only those access entries in which the actor value
matches the actor address in the query. If the wildcard character
('*') is present, then it a match is possible only if each
wildcard character can be replaced with a non-empty character
sequence (one or more characters) to obtain a value identical to
the address in the query.
o Order those remaining access entries:
* Use the exactness of the match with the domain part of the
actor value as the primary key; and,
* Use the exactness of the match with the local part of the actor
value as the secondary key.
o When matching with the domain part, an exact match is the best
match; otherwise, the shorter the wildcard match, the higher the
priority.
For example, if the actor's domain is "bar.foo.example.com", a
match against an entry of "*.foo.example.com" is better than a
match against an entry of "*.example.com".
o When matching with the local part, an exact match is the best
match; otherwise, the shorter the wildcard match, the higher the
priority. This is true regardless of whether the wildcarding is
for subaddress or service. (Note that a local part with a
wildcard subaddress does not have a non-empty match with the same
local part without a subaddress.)
For example, consider these access entries:
<access owner='fred@example.com'
actor='wilma@example.com'
actions='all:all'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred@example.com'
actor='mr.slate@example.com'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred/appl=wb@example.com'
actor='barney/appl=wb@example.com'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe presence:watch'
lastUpdate='2000-05-14T13:20:00-08:00' />
Rose, et. al. Standards Track [Page 12]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
<access owner='fred@example.com'
actor='*@*'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
Briefly:
o For addresses within the "example.com" administrative domain:
* "fred", "wilma", and all APEX services within the "example.com"
administrative domain are allowed access to all operations for
"fred@example.com";
* "mr.slate" is allowed access only to send data through the
relaying mesh to "fred@example.com";
* "barney/appl=wb" is allowed access only to send data to "fred/
appl=wb", a subaddress of "fred@example.com"; and,
* any other address within the "example.com" administrative
domain is allowed access to send data and invoke the
"subscribe" and "watch" operations of the APEX presence service
with respect to "fred@example.com".
o For any address outside the "example.com" administrative domain,
the address is allowed access to send data, regardless of whether
it is an APEX service.
Rose, et. al. Standards Track [Page 13]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -