[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 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----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Tuesday, October 19, 2010 12:00 PM > To: Tyson, Paul H > Cc: xacml; George Inman; Sampo Kellomaki > Subject: Re: [xacml] Telling the PIP where to pull from > > > 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]