OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  Telling the PIP where to pull from

    Posted 10-19-2010 12:19 
    Hi everyone

in the TAS3 project we have been developing the PDP to be able to pull 
various user credentials from different IDPs. We use the SAML/XACML 
protocol to communicate between the PEP and the PDP. One of the things 
we need to do is for the PEP to direct the PIP of the PDP where to go to 
fetch extra user attributes/credentials/claims. The solution we are 
proposing is to put a WSSE security token in the SOAP header of the SAML 
request.

What do the group think about this approach?

Have other ways of directing the PIP been discussed?

Is the group willing to standardise the way that the PEP can dynamically 
inform the PDP/PIP where to pull additional attributes/claims from

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************


  • 2.  RE: [xacml] Telling the PIP where to pull from

    Posted 10-19-2010 12:59 
    Is this something beyond what the "Issuer" attribute can do?

From a semantic perspective, the Issuer attribute has never made sense
to me.  I think of XACML Attributes as predicates for making assertions
about the state of the world, and I don't know what to make of a
situation where Issuer A says one thing about the world and Issuer B
says something else.

It would be different matter if you wanted to consult different sources
based on performance or availability.  Is that the use case?

Regards,
--Paul

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Re: [xacml] Telling the PIP where to pull from

    Posted 10-19-2010 16:01 
    Hi Paul

I dont think the issuer attribute makes much sense either. It is like 
saying that Euros issued by Greece are different to Euros issued by 
France, when in fact they are not. The currency issued by Greece was 
different to the one issued by France when the former were Drachmas and 
the latter were Francs. But a euro is a euro is a euro regardless of the 
issuer.

Turning to the use case, here is one.

The SP requires a credit card from Visa or Mastercard, a frequent flyer 
card from an airline, and a valid username in order to grant access to a 
resource. The user has chosen which cards and issuers to use and has 
authenticated via an IDP which has provided the username. We have built 
a PIP that is capable of aggregating claims/assertions from multiple 
IDPs, providing the PEP tells the PIP which issuers to pull from. The 
PIP may have meta data for hundreds of issuers, but cannot contact them 
all. It has to be directed which ones to go to in real time. This is the 
purpose of putting the WSSE security token in the SOAP header.

regards

David



On 19/10/2010 13:58, Tyson, Paul H wrote:
> Is this something beyond what the "Issuer" attribute can do?
>
>> From a semantic perspective, the Issuer attribute has never made sense
> to me.  I think of XACML Attributes as predicates for making assertions
> about the state of the world, and I don't know what to make of a
> situation where Issuer A says one thing about the world and Issuer B
> says something else.
>
> It would be different matter if you wanted to consult different sources
> based on performance or availability.  Is that the use case?
>
> Regards,
> --Paul
>
>> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 4.  Re: [xacml] Telling the PIP where to pull from

    Posted 10-22-2010 18:34 
    

  


Hi David and Paul,

    
Based on this requirement:
    

    "We have built a PIP that is capable of aggregating
claims/assertions from multiple IDPs, providing the PEP tells the PIP
which issuers to pull from."
    

    
Why can't there simply be one AttributeId, say "...IDPList", which is
of type anyURI, and that this attribute can be multi-valued with each
value being a URI corresponding to one IDP? Then the PIP can use this
list to select from its total list of issuers.

    
Two other comments on the discussion:
    

      
  
    • Regarding "Issuer", my understanding is that one cannot assume
anything about the semantics of a specific AttributeId. i.e. an
AttributeId is a unique identifier and it is up to the users of that
AttributeId to understand the semantics that are associated with it.
Some AttributeIds may never have an Issuer, others may have only one
Issuer, and others may have multiple Issuers. For the multiple Issuers
case, it may be that Policy will only accept a specific set of Issuers
for this specific AttributeId. i.e. Nothing can be assumed, because one
must "know" the semantics in order to properly understand what the
AttributeId represents and how it can be used in some specific
environment.
      • 
  
    • Regarding using a WSSE security token, I think it is not a good
idea to tie any PEP->PDP information flows that are specific to the
communication channel being used between PEP->PDP. I would expect
behavior not to vary from PDP to PDP as a function of the Request and
Response are transmitted. i.e. if two PDPs have identical PolicySets,
then presumably the same Request would get the same Response
independent of the physical location and access mechanism to these PDPs.
      • 

    
At least, that is my view of this discussion so far.

    
    Thanks,
    
    Rich


    
David Chadwick wrote:

    4CBDC06D.6000906@kent.ac.uk" type="cite">Hi Paul

    
I dont think the issuer attribute makes much sense either. It is like
saying that Euros issued by Greece are different to Euros issued by
France, when in fact they are not. The currency issued by Greece was
different to the one issued by France when the former were Drachmas and
the latter were Francs. But a euro is a euro is a euro regardless of
the issuer.

    
Turning to the use case, here is one.

    
The SP requires a credit card from Visa or Mastercard, a frequent flyer
card from an airline, and a valid username in order to grant access to
a resource. The user has chosen which cards and issuers to use and has
authenticated via an IDP which has provided the username. We have built
a PIP that is capable of aggregating claims/assertions from multiple
IDPs, providing the PEP tells the PIP which issuers to pull from. The
PIP may have meta data for hundreds of issuers, but cannot contact them
all. It has to be directed which ones to go to in real time. This is
the purpose of putting the WSSE security token in the SOAP header.

    
regards

    
David



    
On 19/10/2010 13:58, Tyson, Paul H wrote:
    
  
    Is this something beyond what the "Issuer"
attribute can do?

    From a semantic perspective, the Issuer
attribute has never made sense
    
to me.  I think of XACML Attributes as predicates for making assertions
    
about the state of the world, and I don't know what to make of a
    
situation where Issuer A says one thing about the world and Issuer B
    
says something else.

    
It would be different matter if you wanted to consult different sources
    
based on performance or availability.  Is that the use case?

    
Regards,
    
--Paul


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 5.  Re: [xacml] Telling the PIP where to pull from

    Posted 10-29-2010 15:46 
    Hi Rich

On 22/10/2010 19:34, Rich.Levinson wrote:
> Hi David and Paul,
>
> Based on this requirement:
>
>     "We have built a PIP that is capable of aggregating
>     claims/assertions from multiple IDPs, providing the PEP tells the
>     PIP which issuers to pull from."
>
> Why can't there simply be one AttributeId, say "...IDPList",

this was indeed our first design as I outlined in my message of 21 Oct.

  which is of
> type anyURI, and that this attribute can be multi-valued with each value
> being a URI corresponding to one IDP? Then the PIP can use this list to
> select from its total list of issuers.

However this does not provide privacy protection and it assumes that the 
user is known by the same ID at all IDPs. this was fine for grid usage 
where user's have public keys and public DNs. But it is no good for 
Liberty and SAML users who have different PIDs at different IDP-SP pairings.


>
> Two other comments on the discussion:
>
>     * Regarding "Issuer", my understanding is that one cannot assume
>       anything about the semantics of a specific AttributeId. i.e. an
>       AttributeId is a unique identifier and it is up to the users of
>       that AttributeId to understand the semantics that are associated
>       with it. Some AttributeIds may never have an Issuer, others may
>       have only one Issuer, and others may have multiple Issuers. For
>       the multiple Issuers case, it may be that Policy will only accept
>       a specific set of Issuers for this specific AttributeId. i.e.
>       Nothing can be assumed, because one must "know" the semantics in
>       order to properly understand what the AttributeId represents and
>       how it can be used in some specific environment.

the fact that the AttributeID is unique means it must have a unique 
definition. An attribute that has different semantics when issued by 
different IDPs means that it does not have a unique definition, but has 
different definitions depending upon the issuer. Thus it is illogical, 
as in the Euro example I gave in my previous message. If the attributes 
from different issuers are semantically different, they should have 
different AttributeIDs.



>     * Regarding using a WSSE security token, I think it is not a good
>       idea to tie any PEP->PDP information flows that are specific to
>       the communication channel being used between PEP->PDP.

I tend to agree with this. It is a good point. Although one could argue 
that there could be different protocol mappings of the various fields 
for different protocols (although I am not going to argue for this, I 
know someone who might).

regards

David


  I would
>       expect behavior not to vary from PDP to PDP as a function of the
>       Request and Response are transmitted. i.e. if two PDPs have
>       identical PolicySets, then presumably the same Request would get
>       the same Response independent of the physical location and access
>       mechanism to these PDPs.
>
> At least, that is my view of this discussion so far.
>
> Thanks,
> Rich
>
>
> David Chadwick wrote:
>> Hi Paul
>>
>> I dont think the issuer attribute makes much sense either. It is like
>> saying that Euros issued by Greece are different to Euros issued by
>> France, when in fact they are not. The currency issued by Greece was
>> different to the one issued by France when the former were Drachmas
>> and the latter were Francs. But a euro is a euro is a euro regardless
>> of the issuer.
>>
>> Turning to the use case, here is one.
>>
>> The SP requires a credit card from Visa or Mastercard, a frequent
>> flyer card from an airline, and a valid username in order to grant
>> access to a resource. The user has chosen which cards and issuers to
>> use and has authenticated via an IDP which has provided the username.
>> We have built a PIP that is capable of aggregating claims/assertions
>> from multiple IDPs, providing the PEP tells the PIP which issuers to
>> pull from. The PIP may have meta data for hundreds of issuers, but
>> cannot contact them all. It has to be directed which ones to go to in
>> real time. This is the purpose of putting the WSSE security token in
>> the SOAP header.
>>
>> regards
>>
>> David
>>
>>
>>
>> On 19/10/2010 13:58, Tyson, Paul H wrote:
>>> Is this something beyond what the "Issuer" attribute can do?
>>>
>>>> From a semantic perspective, the Issuer attribute has never made sense
>>> to me. I think of XACML Attributes as predicates for making assertions
>>> about the state of the world, and I don't know what to make of a
>>> situation where Issuer A says one thing about the world and Issuer B
>>> says something else.
>>>
>>> It would be different matter if you wanted to consult different sources
>>> based on performance or availability. Is that the use case?
>>>
>>> Regards,
>>> --Paul
>>>
>>>> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 6.  RE: [xacml] Telling the PIP where to pull from

    Posted 06-09-2011 16:03
    I believe we might usefully combine the AML proposal with this one. The original submission is here: http://lists.oasis-open.org/archives/xacml/200907/msg00019.html The files are here: http://www.oasis-open.org/committees/download.php/33416/AZContribution.zipee The basic idea is to allow an AMF file to be returned to provide the information required to locate attribute values. If the information in the proposed AMF is insufficient for your purposes, we can add it. I am overdue in making needed changes to it anyway. It is my opinion that information about attribute locations are likely to come from multiple sources. BTW, I believe the <xacml-samlp:Extensions> element could be used to carry this if that is desired. Hal >
    Original Message


  • 7.  RE: [xacml] Telling the PIP where to pull from

    Posted 11-04-2010 15:47 
    I think Issuer is absolutely required in some environments, where the information may be available from distinct authorities with different associated levels of trust. In some cases the Issuer may also be used to disambiguate the meaning of the attribute value. To pick up on David's example, the dollar is different in Canada, the US, Australia, New Zealand, Hong Kong, Brunei, etc.

I think the issue of whether credential should be the primary construct, rather than attribute is more arguable. It is clear that metadata used for vetting (e.g. expiration date) needs to be associated with the attributes taken from the same credential and not treated as a freestanding attribute which can be combined with any other attribute.

The argument that an attribute in one credential is different from the attribute in a different credential WITH THE SAME ISSUER, seems much weaker to me. It is easy to think of cases like getting an attribute from a Repository where there is no credential involved. In the vast majority of cases, I think that if an organization had conflicting information about an individual (e.g. two different birthdates) they would consider it merely a clerical error to be corrected as soon as noticed. If I am called Harold Lockhart on my military identity card and Hal Lockhart on my military driver's license is that likely to have any significance? 

Still I concede that there may be cases where this is needed. If the Policy is going to operate directly on the credential value, it must be associated with the attribute in some way. 

This subject raises one of the subtle points about XACML. There is an unspecified division of labor between the context handler and the policy evaluation logic. In all implementations, the context handler does a certain amount of work to vet and format the attributes it submits to the PDP. In many cases there can be considerable latitude as to what is put in to code (context handler) and what appears in policy. For example, during the discussion on the 3.0 admin model, I got the impression that Frank Seibelist wanted to put the entire PKI validation logic in XACML policy. At the other end of the scale, some languages (Secpal) assume that the data will be put in canonical format and thus omit the many data formatting functions we have in XACML.

I think that the middle road taken by XACML of leaving the choice to the implementers and deployers provides necessary flexibility, although it does sacrifice some potential interoperability amongst different deployments. When deciding how much vetting or formatting should be done by the context handler vs. the policy there are two main considerations: how dynamic is the processing and how familiar to users will the resulting attribute values be. 

As an example of the first, I would expect that the process of verifying a certificate chain would be relatively constant within an organization or at least within an application, so I would suggest this not be represented in policy. 

As an example of the second, suppose the organization rates all their customers as gold, silver, bronze based on a complex calculation of frequency, size and recentness of transactions. This is reasonable to represent as an attribute since it is familiar to all users in that organization. On the other hand, some kind of risk score, known only to the Security Department would be better to express as a policy based on the attributes it is calculated from.

Hal



> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content