Subject: RE: [XCON] Policies in the data model

From: "Chris Boulton" <[email-masked]>
Date: Tue, 13 Mar 2007 09:03:51 -0000

Gonzalo - I would just like to add to my previous comment.  If, for the
sake of progress, the group decides to bump policies from the Data Model
then I will not object.  The critical path at this moment in time is
progress and not another blockade.

Chris.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: 12 March 2007 18:15
To: Henning Schulzrinne
Cc: XCON; Aki Niemi
Subject: Re: [XCON] Policies in the data model

Hi Henning,

there is an already expired draft that tried and used the common policy 
language to define a conference's policy.

http://www.watersprings.org/pub/id/draft-niemi-xcon-cpcp-rules-00.txt

Maybe this could be a good starting point. XACML has also been mentioned

in this thread. It would be interesting if somebody could have a look at

how XACML could be used for our purposes to see whether or not is a good

fit.

Regarding my question 1) below, there have been answers in favor and 
against including policy in the data model. We need to discuss this in 
more detail.

Cheers,

Gonzalo

Henning Schulzrinne wrote:
> I'll add that it might be interesting to look at the policy work in 
> SIMPLE (common policy, etc.). It takes somewhat of a middle ground, 
> with both more semantically oriented permissions and some operations 
> that are closer to XML elements, although it probably tries to stay 
> on the semantic side rather than, say, specifying Xpaths as
permissions.
> 
> In my personal opinion, it is very hard to make syntactic permissions 
> work well, simply because one often wants to express permissions that 
> span multiple elements and that only make sense if expressed as a 
> whole. Also, syntactic permissions can easily yield meaningless or 
> illegal operations ("remove the parent element that is required").
> 
> On Mar 12, 2007, at 8:58 AM, Gonzalo Camarillo wrote:
> 
>  > Hi,
>  >
>  > the biggest open issue in the data model is policies. We need to 
>  > decide:
>  >
>  > 1) whether policies (e.g., who can perform certain tasks like 
>  > adding or removing a user) are in or out of the data model's scope.
>  >
>  > 2) if they are in scope, whether we follow a syntactic (e.g., user 
>  > A can modify element <foo>) or semantic (e.g., user A can add new 
>  > users to the conference) approach.
>  >
>  > 3) the granularity to use. Whether to have pre-defined roles where 
>  > higher roles are authorized to perform a super set of the 
>  > operations performed by lower roles, or to have groups of users 
>  > (similar to Unix groups).
>  >
>  > I would like to encourage people to discuss these issues because, 
>  > otherwise, it will be impossible to make any progress on this
field.
>  >
>  > Cheers,
>  >
>  > Gonzalo
>  >
>  >
>  > _______________________________________________
>  > XCON mailing list
>  > [email-masked]
>  > https://www1.ietf.org/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Mar 2007 08:07:13 -0400

I would argue that policies are generally a rat-hole and we may want  
to punt on these for now. In SIMPLE, it has taken years to finish the  
policy documents, and the problem there is much more constrained.  
(And, as one of the co-authors, I'm pretty sure the solution is over- 
engineered.)

Or, alternatively, have an extremely minimal, but extensible, policy  
set that addresses only two questions:

- who can modify the conference description
- who can create a conference from a template

Once you get to the "can create conferences with no more than 5  
members, but only on alternate Tuesdays that aren't holidays", we'll  
be celebrating the tenth anniversary of the WG.

If we can't quickly agree on a minimalist set of policies, it's a  
good sign that this isn't ready for protocol work.

Henning

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Mar 2007 14:24:22 +0100

Actually the idea of the authors of the data model draft from the very
beginning was to have a minimalist set of policies good enough to define
the basic actions in a conference (see section 3.7.2. of the 03 version
). 

>From the 00 version of the draft we defined a semantic approach
following the guidelines of the "Conference Policy Authorization Rules"
draft
(http://www.watersprings.org/pub/id/draft-niemi-xcon-cpcp-rules-00.txt)
and the "common policy" draft (draft-ietf-geopriv-common-policy).

This information has been removed from the last version of the data
model because some people complained about the idea. 

We can introduce that information again in the draft making the
modifications needed to adapt it to the requirements of the WG.

Oscar 

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: 13. maaliskuuta 2007 14:07
To: Chris Boulton
Cc: Aki Niemi; Gonzalo Camarillo (JO/LMF); XCON
Subject: Re: [XCON] Policies in the data model

I would argue that policies are generally a rat-hole and we may want to
punt on these for now. In SIMPLE, it has taken years to finish the
policy documents, and the problem there is much more constrained.  
(And, as one of the co-authors, I'm pretty sure the solution is over-
engineered.)

Or, alternatively, have an extremely minimal, but extensible, policy set
that addresses only two questions:

Once you get to the "can create conferences with no more than 5 members,
but only on alternate Tuesdays that aren't holidays", we'll be
celebrating the tenth anniversary of the WG.

If we can't quickly agree on a minimalist set of policies, it's a good
sign that this isn't ready for protocol work.

Henning

On Mar 13, 2007, at 5:03 AM, Chris Boulton wrote:

> Gonzalo - I would just like to add to my previous comment.  If, for 
> the sake of progress, the group decides to bump policies from the Data

> Model then I will not object.  The critical path at this moment in 
> time is progress and not another blockade.
>
> Chris.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Mar 2007 22:05:36 +0200

Hi,

I agree with Henning. Let's finish the basic stuff first and worry about 
the complicated stuff later so that we can make some progress.

Cheers,

Gonzalo

Henning Schulzrinne wrote:
> policy documents, and the problem there is much more constrained. (And, 
> as one of the co-authors, I'm pretty sure the solution is over-engineered.)
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 16 Mar 2007 17:28:43 +0100

Dear all,

I've been thinking about the policy issue again and I would like to better
explain why I was suggesting the adoption of a framework like XACML, which
clearly envisages a neat separation between the data model and the policies.

DISCLAIMER: this is going to be a long mail...just delete it if you're not
interested in the subject...

First of all, I remind you that the core RBAC (Role Based Access Control) model
is based on the following elements:

----------------------------------------------------------------------------
RBAC element        | XCON related concept | XACML-based implementation
----------------------------------------------------------------------------
1.        Users     | XCON users           | implemented through XACML subjects
2.        Roles     | XCON roles           | implemented through XACML subject
attributes
3.        Objects   | XCON data model      | implemented through XACML
resources
4.       Operations | XCON operations      | implemented through XACML actions
5.       Permissions| XCON mgmt framework  | implemented through  XACML Role
<PolicySet> and Permission <PolicySet> instances (see below...)
-------------------------------------------------------------------------------

Based on the OASIS document "Core and hierarchical role based access control
(RBAC) profile of XACML v2.0", available at
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf,
I have elaborated a simple example which I hope helps clarify my idea.

Let us suppose we have two distinct roles:

1- conference creator --> can create a new conference
2- conference user --> can just join an existing conference

Clearly, a conference creator can also play the role of a conference user...i
RBAC this means that a conference creator role is "junior" to a conference user
role.

We can first of all use XACML to define such roles.

The following XACML permission policy set defines permissions associated with
the conference creator role...

<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"          
    PolicySetId="PPS:creator:role"          
  
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides">

  <!-- Permissions for the creator role -->          
  <Policy PolicyId="Permissions:specifically:for:the:creator:role"          
    
RuleCombiningAlgId:"urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:
permit-overrides">          
          
    <!-- Permission to create a new XCON conference -->          
    <Rule RuleId="Permission:to:create:an:XCON:conference"          
        Effect="Permit">          
      <Target>          
        <Resources>          
          <Resource>          
            <ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">          
              <attributeValue          
DataType="http://www.w3.org/2001/XMLSchema#string">XCON
conference</AttributeValue>          
              <ResourceAttributeDesignator          
                
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"          
                  DataType="http://www.w3.org/2001/XMLSchema#string"/>         

            </ResourceMatch>          
          </Resource>          
        </Resources>          
        <actions>          
          <action>          
            <actionMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">          
              <attributeValue          
                
DataType="http://www.w3.org/2001/XMLSchema#string">create</AttributeValue>      
   
              <actionAttributeDesignator          
                  AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"   

                  DataType="http://www.w3.org/2001/XMLSchema#string"/>         

            </ActionMatch>          
          </Action>          
        </Actions>          
      </Target>          
    </Rule>          
  </Policy>          
          
  <!-- Include permissions associated with conference user role -->          
  <PolicySetIdReference>PPS:user:role</PolicySetIdReference>          
</PolicySet>

The following permission policy set, in turn, defines the permissions
associated
with the conference user role (i.e. joining an existing conference...)

<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"          
     PolicySetId="PPS:user:role"          
    
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides">

  <!-- Permissions for the user role -->          
  <Policy PolicyId="Permissions:specifically:for:the:user:role"          
    
RuleCombiningAlgId=""urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">

    <!-- Permission to join an existing conference -->          
    <Rule RuleId="Permission:to:join:an:XCON:conference"          
        Effect="Permit">          
      <Target>          
        <Resources>          
          <Resource>          
            <ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">          
              <attributeValue          
DataType="http://www.w3.org/2001/XMLSchema#string">XCON
conference</AttributeValue>          
              <ResourceAttributeDesignator          
                
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"          
                  DataType="http://www.w3.org/2001/XMLSchema#string"/>         

            </ResourceMatch>          
          </Resource>          
        </Resources>          
        <actions>          
          <action>          
            <actionMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">          
              <attributeValue          
                  DataType="http://www.w3.org/2001/XMLSchema#string">join
</AttributeValue>          
              <actionAttributeDesignator          
                  AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"   

                  DataType="http://www.w3.org/2001/XMLSchema#string"/>         

            </ActionMatch>          
          </Action>          
        </Actions>          
      </Target>          
    </Rule>          
  </Policy>          
</PolicySet>        

Once done with the permission policy sets, we can move to role policy sets,
which are used in order to associate policy permission sets with specific
roles.
This is done by using a <PolicySetIdReference> tag which points to the
permission policy set associated with a specific role.
For the creator role...

<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"          
    PolicySetId="RPS:creator:role"          
  
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:
permit-overrides">          
  <Target>          
    <Subjects>          
      <Subject>          
        <SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">          
          <attributeValue          
            
DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:example:role-values:creator</AttributeValue>

          <SubjectAttributeDesignator          
              AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"          
              DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>          
        </SubjectMatch>          
      </Subject>          
    </Subjects>          
  </Target>          
          
  <!-- Use permissions associated with the creator role -->          
  <PolicySetIdReference>PPS:creator:role</PolicySetIdReference>          
</PolicySet>        
  
Similarly, for the user role:

<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"          
    PolicySetId="RPS:user:role"          
  
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:
permit-overrides">          
  <Target>          
    <Subjects>          
      <Subject>          
        <SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">          
          <attributeValue          
            
DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:example:role-values:user</AttributeValue>

          <SubjectAttributeDesignator          
              AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"          
              DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>          
        </SubjectMatch>          
      </Subject>          
    </Subjects>          
  </Target>          
          
  <!-- Use permissions associated with the user role -->          
  <PolicySetIdReference>PPS:user:role</PolicySetIdReference>          
</PolicySet>        

That's all. With these policies in place, acess to the (XCON data model...)
conference object should be appropriately controlled.
Coming to the issue of assigning users to roles, which is BTW outside the scope
of an XACML Policy Decision Point (PDP), can be done through
so-called role-assignment policies. Such assignment should be under the
responsibility of an ad-hoc dedicated Role Assignment entity.

In the following example, we have a role assignment policy with two rules: the
first rule states that Simon is allowed to play the "creator" role; the second

states that Tobia and Lorenzo are just allowed to play the "user" role, but
only
between 9 am and 4 pm.

<Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"          
    PolicyId="Role:Assignment:Policy"          
  
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">
          
<!-- Creator role requirements rule -->          
<Rule RuleId="creator:role:requirements" Effect="Permit">          
  <Target>          
    <Subjects>          
      <Subject>          
        <SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">          
          <attributeValue          
              
DataType="http://www.w3.org/2001/XMLSchema#string">Simon</AttributeValue>       
  
          <SubjectAttributeDesignator          
               AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"    

               DataType="http://www.w3.org/2001/XMLSchema#string"/>          
        </SubjectMatch>          
      </Subject>          
    </Subjects>          
    <Resources>          
      <Resource>          
        <ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">          
          <attributeValue          
            
DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:example:role-values:creator</AttributeValue>

          <ResourceAttributeDesignator          
              AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"          
              DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>          
        </ResourceMatch>          
      </Resource>          
    </Resources>          
    <actions>          
      <action>          
        <actionMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">          
          <attributeValue          
            
DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:enableRole</AttributeValue>

          <actionAttributeDesignator          
              AttributeId="urn:oasis:names:tc:xacml:1.0:action:
action-id"          
              DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>          
        </ActionMatch>          
      </Action>          
    </Actions>          
  </Target>          
</Rule>

<!--  User role requirements rule -->          
<Rule RuleId="user:role:requirements" Effect="Permit">          
  <Target>          
    <Subjects>          
      <Subject>          
        <SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">          
          <attributeValue          
            
DataType="http://www.w3.org/2001/XMLSchema#string">Tobia</AttributeValue>       
  
          <SubjectAttributeDesignator          
              AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"     
    
              DataType="http://www.w3.org/2001/XMLSchema#string"/>          
        </SubjectMatch>          
      </Subject>          
      <Subject>          
        <SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">          
          <attributeValue          
            
DataType="http://www.w3.org/2001/XMLSchema#string">Lorenzo</AttributeValue>     

          <SubjectAttributeDesignator          
              AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"     
    
              DataType="http://www.w3.org/2001/XMLSchema#string"/>          
        </SubjectMatch>          
      </Subject>          
    </Subjects>          
    <Resources>          
      <Resource>          
        <ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">          
          <attributeValue          
            
DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:example:role-values:user</AttributeValue>

          <ResourceAttributeDesignator          
              AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"          
              DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>          
        </ResourceMatch>          
      </Resource>          
    </Resources>          
    <actions>          
      <action>          
        <actionMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">          
          <attributeValue          
            
DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:enableRole</AttributeValue>

          <actionAttributeDesignator          
              AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"       
  
              DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>          
        </ActionMatch>          
      </Action>          
    </Actions>          
  </Target>          
  <Condition>          
   <apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">          
    <apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equal">  

      <apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">          
        <EnvironmentAttributeDesignator          
            AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time" 

            DataType="http://www.w3.org/2001/XMLSchema#time"/>          
      </Apply>          
      <attributeValue          
         DataType="http://www.w3.org/2001/XMLSchema#time">9h</AttributeValue>   

    </Apply>          
    <apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-less-than-or-equal">     

      <apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">          
        <EnvironmentAttributeDesignator          
            AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time" 

            DataType="http://www.w3.org/2001/XMLSchema#time"/>          
      </Apply>          
      <attributeValue          
          DataType="http://www.w3.org/2001/XMLSchema#time">16h</AttributeValue> 

   </Apply>          
   </Apply>          
  </Condition>          
</Rule>        
          
</Policy>        

I hope this helps clarify my point of view.

Cheers,

Simon
-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: [email-masked]

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

Scrive Henning Schulzrinne <[email-masked]>:

> > the

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.