OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Telling the PIP where to pull from


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-----
> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
> Sent: Friday, October 29, 2010 11:44 AM
> To: Rich.Levinson
> Cc: Tyson, Paul H; xacml; George Inman; Sampo Kellomaki
> Subject: Re: [xacml] Telling the PIP where to pull from
> 
> 
> 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-----
> >>>> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
> >>>> Sent: Tuesday, October 19, 2010 07:17
> >>>> To: xacml
> >>>> Cc: George Inman; Sampo Kellomaki
> >>>> Subject: [xacml] Telling the PIP where to pull from
> >>>>
> >>>> 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
> >>>>
> >>>> *****************************************************************
> >>>>
> >>>> 
> ---------------------------------------------------------------------
> >>>> To unsubscribe from this mail list, you must leave the 
> OASIS TC that
> >>>> generates this mail. Follow this link to all your TCs in 
> OASIS at:
> >>>> 
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>>
>>

-- 

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

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]