[sip-comm-dev] XCAP Presence Authorization Rules Strategies


#1

Hello,

I'm going to add Presence Authorization Rules support for XCAP (rfc5025).
I offer the following strategies:

Strategy1:
1. Read the whole XCAP contact list.
2. Create Rules according to XCAP contacts (references will be skipped),
i.e. create our own "white" list (with full permissions) and add to it all
XCAP contacts.
3. Delete all other rules and save only our own "white" list.

Advantages:
Easy to implement.
Some clients: Mercuro IMS Client, Oracle Communicator uses it.
Disadvantages:
Can lose the rules created by another clients.

Strategy2:
1. Read the whole XCAP contact list.
2. Find in the Rules XCAP contacts from point1.
    2.1. Create our own "white" list (with full permissions).
    2.1. If contacts situated in the "black" list - move them into the our
"white" list.
    2.2. If contacts is not in the list - add them into the our own "white"
list.
    2.3. *Do not clear what to do if contacts are situated **not **in the
our "white" list (others "white" lists can contain different additional
permissions).*
    2.4. *Do not clear what to do with the contacts which are represented in
the Rules but not in the XCAP contacts.*

Advantages:
Also can lose the rules created by another clients but it will try the save
as much as it possible.
Disadvantages:
Hard to implement.

Can you please tell me your thoughts about these strategies?

Thanks, Grigorii


#2

Hey Grigorii,

На 16.06.10 10:54, Grigorii Balutsel написа:

Hello,

I'm going to add Presence Authorization Rules support for XCAP (rfc5025).
I offer the following strategies:

Strategy1:
1. Read the whole XCAP contact list.
2. Create Rules according to XCAP contacts (references will be skipped),
i.e. create our own "white" list (with full permissions) and add to it
all XCAP contacts.
3. Delete all other rules and save only our own "white" list.

Advantages:
Easy to implement.
Some clients: Mercuro IMS Client, Oracle Communicator uses it.
Disadvantages:
Can lose the rules created by another clients.

Strategy2:
1. Read the whole XCAP contact list.
2. Find in the Rules XCAP contacts from point1.

Can you please explain what you mean by Rules?

    2.1. Create our own "white" list (with full permissions).
    2.1. If contacts situated in the "black" list - move them into the
our "white" list.

Not sure about this one. Could you please explain what a black list is
and why you would want to move contacts from inside into our whitelist?

    2.2. If contacts is not in the list

Not sure here either. If which contact is not on which list?

- add them into the our own "white" list.
    2.3. *Do not clear what to do if contacts are situated **not **in
the our "white" list (others "white" lists can contain different
additional permissions).*

Did you mean that you are not clear what to do with contacts that were
already on the server stored whitelist but that are not among those that
were in the server stored contact list? If, yes, then I guess following
the logic of "Strategy 2" would mean simply leaving them be.

    2.4. *Do not clear what to do with the contacts which are
represented in the Rules but not in the XCAP contacts.*

Ah! The Rules again :). Would need to know what they are.

Cheers,
Emil

···

Advantages:
Also can lose the rules created by another clients but it will try the
save as much as it possible.
Disadvantages:
Hard to implement.

Can you please tell me your thoughts about these strategies?

Thanks, Grigorii

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hello Emil,

Let me explain more detailed:

Authorization policies has so-called rules - they describe what user is
allowed to do and what is not.
Rule contains special permissions for SIP services, devices and persons.
These permissions can be set in different ways. For example it is possible
to specify all users situated in example.com to send chat
messages/calls/presence/mails or specify concrete users that are not allowed
to do it and so on. More over it is possible to specify additional not
specified in the RFC permissions. Also it is possible to set full
permissions for concrete users.

So the first strategy is:
Create our own rule (with special id) and put there all users from the
contact list and set to them full permissions.

The second strategy is:
Try to analyze the rules - here we have some problems:
1. We have to find our users in the rules. For example user's can be
described as:

<identity>
  <one id="sip:alice@example.com"/>
  <one id="tel:+1-212-555-1234" />
  <one id="mailto:bob@example.net <bob@example.net>"/>
</identity>

or

<identity>

  <many>

    <except domain="example.com"/>

    <except domain="example.org"/>

    <except id="sip:alice@bad.example.net"/>

  </many>

</identity>

or

<identity>

  <many domain="example.com">

    <except id="sip:alice@example.com"/>

    <except id="sip:bob@example.com"/>

  </many>

</identity>

2. If user situated in the rule we have to analyze what exactly he is
allowed to do and what is not.

There are can be a lot of rules with the sets of permissions, moreover it is
possible to have two rules - one is allowed to do it, another is not allowed
to do the same thing (in that case server will decide by his own what to do
and how to process it).

If user is not allowed to do smth what we have to do?
If user is allowed only to chat but not allowed to see presence what we have
to do?
and so on.

So my idea - to use strategy1 (create our own rule) and save all other rules
(created by another clients). If user will use different clients - he has to
understand that in that case it is possible to have problems.

Thanks, Grigorii

···

2010/6/18 Emil Ivov <emcho@sip-communicator.org>

Hey Grigorii,

На 16.06.10 10:54, Grigorii Balutsel написа:
> Hello,
>
> I'm going to add Presence Authorization Rules support for XCAP (rfc5025).
> I offer the following strategies:
>
> Strategy1:
> 1. Read the whole XCAP contact list.
> 2. Create Rules according to XCAP contacts (references will be skipped),
> i.e. create our own "white" list (with full permissions) and add to it
> all XCAP contacts.
> 3. Delete all other rules and save only our own "white" list.
>
> Advantages:
> Easy to implement.
> Some clients: Mercuro IMS Client, Oracle Communicator uses it.
> Disadvantages:
> Can lose the rules created by another clients.
>
> Strategy2:
> 1. Read the whole XCAP contact list.
> 2. Find in the Rules XCAP contacts from point1.

Can you please explain what you mean by Rules?

> 2.1. Create our own "white" list (with full permissions).
> 2.1. If contacts situated in the "black" list - move them into the
> our "white" list.

Not sure about this one. Could you please explain what a black list is
and why you would want to move contacts from inside into our whitelist?

> 2.2. If contacts is not in the list

Not sure here either. If which contact is not on which list?

>- add them into the our own "white" list.
> 2.3. *Do not clear what to do if contacts are situated **not **in
> the our "white" list (others "white" lists can contain different
> additional permissions).*

Did you mean that you are not clear what to do with contacts that were
already on the server stored whitelist but that are not among those that
were in the server stored contact list? If, yes, then I guess following
the logic of "Strategy 2" would mean simply leaving them be.

> 2.4. *Do not clear what to do with the contacts which are
> represented in the Rules but not in the XCAP contacts.*

Ah! The Rules again :). Would need to know what they are.

Cheers,
Emil
>
> Advantages:
> Also can lose the rules created by another clients but it will try the
> save as much as it possible.
> Disadvantages:
> Hard to implement.
>
> Can you please tell me your thoughts about these strategies?
>
> Thanks, Grigorii

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#4

Hello,

I've implemented XCAP contacts and authorization policies.

It is situated in /branches/gsoc10/xcap in SVN.

To test it - do the following steps:
1. Register your account on http://sip2sip.info/ server
2. Backup your contact list (meta contacts have some bugs so it is better to
back up :slight_smile: )
3. Add your sip account (from point1) into Sip Communicator. In the special
field set XCAP server (for sip2sip.info it is
https://xcap.sipthor.net/xcap-root@sip2sip.info)

After that you will be able to test add/remove/move contacts and groups.

NOTE: If you want to get presence events from another users - you and them
have to add each other to the contact list.
NOTE: Do not use your contact list with another SIP clients as it is
possible to lose some of its data (will be fixed soon).

If you will find some issues please let me know.

This week I'm going to spend for bug fixing.

Thanks, Grigorii

···

18 июня 2010 г. 15:58 пользователь Grigorii Balutsel < grigorii.balutsel@gmail.com> написал:

Hello Emil,

Let me explain more detailed:

Authorization policies has so-called rules - they describe what user is
allowed to do and what is not.
Rule contains special permissions for SIP services, devices and persons.
These permissions can be set in different ways. For example it is possible
to specify all users situated in example.com to send chat
messages/calls/presence/mails or specify concrete users that are not allowed
to do it and so on. More over it is possible to specify additional not
specified in the RFC permissions. Also it is possible to set full
permissions for concrete users.

So the first strategy is:
Create our own rule (with special id) and put there all users from the
contact list and set to them full permissions.

The second strategy is:
Try to analyze the rules - here we have some problems:
1. We have to find our users in the rules. For example user's can be
described as:

<identity>
  <one id="sip:alice@example.com"/>
  <one id="tel:+1-212-555-1234" />
  <one id="mailto:bob@example.net <bob@example.net>"/>

</identity>

or

<identity>

  <many>

    <except domain="example.com"/>

    <except domain="example.org"/>

    <except id="sip:alice@bad.example.net"/>

  </many>

</identity>

or

<identity>

  <many domain="example.com">

    <except id="sip:alice@example.com"/>

    <except id="sip:bob@example.com"/>

  </many>

</identity>

2. If user situated in the rule we have to analyze what exactly he is
allowed to do and what is not.

There are can be a lot of rules with the sets of permissions, moreover it
is possible to have two rules - one is allowed to do it, another is not
allowed to do the same thing (in that case server will decide by his own
what to do and how to process it).

If user is not allowed to do smth what we have to do?
If user is allowed only to chat but not allowed to see presence what we
have to do?
and so on.

So my idea - to use strategy1 (create our own rule) and save all other
rules (created by another clients). If user will use different clients - he
has to understand that in that case it is possible to have problems.

Thanks, Grigorii

2010/6/18 Emil Ivov <emcho@sip-communicator.org>

Hey Grigorii,

На 16.06.10 10:54, Grigorii Balutsel написа:
> Hello,
>
> I'm going to add Presence Authorization Rules support for XCAP
(rfc5025).
> I offer the following strategies:
>
> Strategy1:
> 1. Read the whole XCAP contact list.
> 2. Create Rules according to XCAP contacts (references will be skipped),
> i.e. create our own "white" list (with full permissions) and add to it
> all XCAP contacts.
> 3. Delete all other rules and save only our own "white" list.
>
> Advantages:
> Easy to implement.
> Some clients: Mercuro IMS Client, Oracle Communicator uses it.
> Disadvantages:
> Can lose the rules created by another clients.
>
> Strategy2:
> 1. Read the whole XCAP contact list.
> 2. Find in the Rules XCAP contacts from point1.

Can you please explain what you mean by Rules?

> 2.1. Create our own "white" list (with full permissions).
> 2.1. If contacts situated in the "black" list - move them into the
> our "white" list.

Not sure about this one. Could you please explain what a black list is
and why you would want to move contacts from inside into our whitelist?

> 2.2. If contacts is not in the list

Not sure here either. If which contact is not on which list?

>- add them into the our own "white" list.
> 2.3. *Do not clear what to do if contacts are situated **not **in
> the our "white" list (others "white" lists can contain different
> additional permissions).*

Did you mean that you are not clear what to do with contacts that were
already on the server stored whitelist but that are not among those that
were in the server stored contact list? If, yes, then I guess following
the logic of "Strategy 2" would mean simply leaving them be.

> 2.4. *Do not clear what to do with the contacts which are
> represented in the Rules but not in the XCAP contacts.*

Ah! The Rules again :). Would need to know what they are.

Cheers,
Emil
>
> Advantages:
> Also can lose the rules created by another clients but it will try the
> save as much as it possible.
> Disadvantages:
> Hard to implement.
>
> Can you please tell me your thoughts about these strategies?
>
> Thanks, Grigorii

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31