[sr-dev] git:master: xcap_server: support parsing oma pres-rules auid

Iñaki Baz Castillo ibc at aliax.net
Wed Sep 29 23:46:40 CEST 2010


2010/9/29 Daniel-Constantin Mierla <miconda at gmail.com>:
>> i understand that oma resource lists stored in xcap server can contain
>> references to external lists stored somewhere else.  xcap server should
>> thus be able to follow those references, not just store xml docs.
>>
> to understand that xcap server has to fetch the RL from other servers?

Yes, it could.


> IMO,
> this might be a security issue

IMHO in XCAP all is a security issue. pres-rules and resource-lists
document contain absolute HTTP uris refering ot other documents of
subnodes in other documents (in same or different XCAP server). If you
decide (the provider) to change the domain or migrate from HTTP to
HTTPS, then all the documents get corrupted.


> Anyhow, might be different that thought, since maybe you refer to RLS
> implementation and not xcap server:
> http://kamailio.org/docs/modules/stable/modules_k/rls.html

As I said, in OMA specs pres-rules contains absolute HTTP links to
<list> elements in resource-lists document. Here is a OMA pres-rules
document (extracted from
OMA-WP-PRS_1_1_Implementation_Guidelines-20081209-A.pdf):



<?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset
xmlns:ocp="urn:oma:xml:xdm:common-policy"
xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
xmlns:cr="urn:ietf:params:xml:ns:common-policy">

<!-- This rule describes that the Presentity has access to her/his own
Presence Information -->
<cr:rule id="wp_prs_allow_own">
<cr:conditions>
<cr:identity>
<cr:one id="sip:joe at example.com"/>
</cr:identity>
</cr:conditions>
<cr:actions>
<pr:sub-handling>allow</pr:sub-handling>
</cr:actions>
<cr:transformations>
<pr:provide-services>
<pr:all-services/>
</pr:provide-services>
<pr:provide-persons>
<pr:all-persons/>
</pr:provide-persons>
<pr:provide-devices>
<pr:all-devices/>
</pr:provide-devices>
<pr:provide-all-attributes/>
</cr:transformations>
</cr:rule>

<!-- This rule describes how an anonymous Watcher’s request shall be handled -->
<cr:rule id="wp_prs_block_anonymous">
<cr:conditions>
<ocp:anonymous-request/>
</cr:conditions>
<cr:actions>
<pr:sub-handling>block</pr:sub-handling>
</cr:actions>
</cr:rule>

<!-- This rule describes that a request from a Watcher not listed in
any other rule is to be
confirmed. -->
<cr:rule id="wp_prs_unlisted">
<cr:conditions>
<ocp:other-identity/>
</cr:conditions>
<cr:actions>
<pr:sub-handling>confirm </pr:sub-handling>
</cr:actions>
</cr:rule>

<!-- This rule describes that a Watcher is granted access to all
Presence Information if its user
URI is included in the “oma_grantedcontacts” URI List in Shared XDMS-->
<cr:rule id="wp_prs_grantedcontacts">
<cr:conditions>
<ocp:external-list>
<ocp:entry anc="http://xcap.example.org/resource-lists/users/
sip:joe at example.org/index/~~/resource-lists/list%5B at name=%22oma_grantedcontacts%22%5D"/>
</ocp:external-list>
</cr:conditions>
<cr:actions>
<pr:sub-handling>allow</pr:sub-handling>
</cr:actions>
<cr:transformations>
<pr:provide-services>
<pr:all-services/>
</pr:provide-services>
<pr:provide-persons>
<pr:all-persons/>
</pr:provide-persons>
<pr:provide-devices>
<pr:all-devices/>
</pr:provide-devices>
<pr:provide-all-attributes/>
</cr:transformations>
</cr:rule>

<!-- This rule describes that a Watcher is blocked from accessing all
Presence Information if its
user URI is included in the oma_blockedcontacts list. -->
<cr:rule id="wp_prs_blockedcontacts">
<cr:conditions>
<ocp:external-list>
<ocp:entry anc="http://xcap.example.org/resource-lists/users/
sip:joe at example.org/index/~~/resource-lists/list%5B at name=%22oma_blockedcontacts%22%5D"/>
</ocp:external-list>
</cr:conditions>
<cr:actions>
<pr:sub-handling>block </pr:sub-handling>
</cr:actions>
</cr:rule>

<!--This rule describes that a single user is granted access to a
certain set of Presence
Information -->
<cr:rule id="wp_prs_allow_one_1">
<cr:conditions>
<cr:identity>
<cr:one id="sip:bob at example.com "/>
</cr:identity>
</cr:conditions>
<cr:actions>
<pr:sub-handling>allow</pr:sub-handling>
</cr:actions>
<cr:transformations>
<pr:provide-persons>
<pr:all-persons/>
</pr:provide-persons>
<pr:provide-activities>true</pr:provide-activities>
</cr:transformations>
</cr:rule>

<!--This rule describes that users on a single list in Shared XDMS is
granted access to a certain
set of Presence Information. -->
<cr:rule id="wp_prs_allow_onelist_1">
<cr:conditions>
<ocp:external-list>
<ocp:entry anc="http://xcap.example.org/resource-lists/users/
sip:joe at example.org/index/~~/resource-lists/list% 5B at name=% 22list-e% 22% 5D"/>
</ocp:external-list>
</cr:conditions>
<cr:actions>
<pr:sub-handling>allow</pr:sub-handling>
</cr:actions>
<cr:transformations>
<pr:provide-persons>
<pr:all-persons/>
</pr:provide-persons>
<pr:provide-status-icon>true</pr:provide-status-icon>
</cr:transformations>
</cr:rule>

<!--This rule describes that a single user is ‘polite-block’ed from
accessing any Presence
Information. -->
<cr:rule id="wp_prs_one_1">
<cr:conditions>
<cr:identity>
<cr:one id="sip:jason at example.com"/>
</cr:identity>
</cr:conditions>
<cr:actions>
<pr:sub-handling>polite-block</pr:sub-handling>
</cr:actions>
<cr:transformations/>
</cr:rule>

<!--This rule describes that users on a single list in Shared XDMS is
‘polite-block’ed from
accessing any Presence Information. -->
<cr:rule id="wp_prs_onelist_1">
<cr:conditions>
<ocp:external-list>
<ocp:entry anc="http://xcap.example.org/resource-lists/users/
sip:joe at example.org/index/~~/resource-lists/list%5B at name=%22list-c%22%5D"/>
</ocp:external-list>
</cr:conditions>
<cr:actions>
<pr:sub-handling>polite-block</pr:sub-handling>
</cr:actions>
<cr:transformations/>
</cr:rule>
</cr:ruleset>




> On another hand, pres-rules is about the rules to allow watchers and
> manipulate presence information. But maybe in oma this document can have
> external references as well.

Yes it has.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>



More information about the sr-dev mailing list