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:
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:]
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:
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
