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

Daniel-Constantin Mierla miconda at gmail.com
Thu Sep 30 12:53:30 CEST 2010



On 9/29/10 11:46 PM, Iñaki Baz Castillo wrote:
> 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.

Agree. As expressed in previous email, the market didn't show the need 
for external references (to my knowledge so far).

If it was me, I would keep the documents on xcap server only with 
contacts. Then each user has its own private contacts list, but there 
can be kind of public (or shared) contacts lists (say: support group, 
sales, a.s.o). that the sip client can download separately and then 
mixes in its GUI as it wants, based on client capabilities and user wishes.

I see xcap as a storage engine, in the way that if I start the same SIP 
client on a different system, it is able to download configuration and 
contact lists. But putting the server to do client jobs is a wrong 
architecture.

Cheers,
Daniel


>> 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.
>
>

-- 
Daniel-Constantin Mierla
http://www.asipto.com




More information about the sr-dev mailing list