[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]